I use wireless so seldom that it seems like each time I need it, it's
a brand new adventure finding out what has changed since the last time
to make it break in a new and exciting way.
This week's wi-fi adventure involved Ubuntu's current "Gutsy Gibbon"
release and my prism54 wireless card. I booted the machine,
switched to the right
(a href="http://shallowsky.com/linux/networkSchemes.html">network
scheme, inserted the card, and ... no lights.
ifconfig -a showed the card on eth1 rather
than eth0.
After some fiddling, I ejected the card and re-inserted it; now
ifconfig -a showed it on eth2. Each time I
inserted it, the number incremented by one.
Ah, that's something I remembered from
Debian
Etch -- a problem with the udev "persistent net rules" file in
/etc/udev.
Sure enough, /etc/udev/70-persistent-net.rules had two entries
for the card, one on eth1 and the other on eth2. Ejecting and
re-inserting added another one for eth3. Since my network scheme is
set up to apply to eth0, this obviously wouldn't work.
A comment in that file says it's generated from
75-persistent-net-generator.rules. But unfortunately,
the rules uesd by that file are undocumented and opaque -- I've never
been able to figure out how to make a change in its behavior.
I fiddled around for a bit, then gave up and chose the brute force
solution:
Edit /etc/udev/70-persistent-net.rules to give the
device the right name (eth1, eth0 or whatever).
And that worked fine. Without 75-persistent-net-generator.rules
getting in the way, the name seen in 70-persistent-net.rules
works fine and I'm able to use the network.
The weird thing about this is that I've been using Gutsy with my wired
network card (a 3com) for at least a month now without this problem
showing up. For some reason, the persistent net generator doesn't work
for the Prism54 card though it works fine for the 3com.
A scan of the Ubuntu bug repository reveals lots of other people
hitting similar problems on an assortment of wireless cards;
bug
153727 is a fairly typical report, but the older
bug 31502
(marked as fixed) points to a likely reason this is apparently so
common on wireless cards -- apparently some of them report the wrong
MAC address before the firmware is loaded.
I had a chance to spend a day at the AGU conference last week. The
American Geophysical Union is a fabulous conference -- something like
14,000 different talks over the course of the week, on anything
related to earth or planetary sciences -- geology, solar system
astronomy, atmospheric science, geophysics, geochemistry, you name it.
I have no idea how regular attendees manage the information overload
of deciding which talks to attend. I wasn't sure how I would, either,
but I started by going
through the schedule
for the day I'd be there, picking out a (way too long) list of
potentially interesting talks, and saving them as lines in a file.
Now I had a file full of lines like:
1020 U22A MS 303 Terrestrial Impact Cratering: New Insights Into the Cratering Process From Geophysics and Geochemistry II
Fine, except that I couldn't print out something like that -- printers
stop at 80 columns. I could pass it through a program like "fold" to
wrap the long lines, but then it would be hard to scan through quickly
to find the talk titles and room numbers. What I really wanted was to
wrap it so that the above line turned into something like:
1020 U22A MS 303 Terrestrial Impact Cratering: New Insights
Into the Cratering Process From Geophysics
and Geochemistry II
But how to do that? I stared at it for a while, trying to figure out
whether there was a clever vim substitute that could handle it.
I asked on a couple of IRC channels, just in case there was some
amazing Linux smart-wrap utility I'd never heard of.
I was on the verge of concluding that the answer was no, and that I'd
have to write a python script to do the wrapping I wanted, when
Mikael emitted a burst of line noise: %s/\(.\{72\}\)\(.*\)/\1^M^I^I^I\2/
Only it wasn't line noise. Seems Mikael just happened to have been
reading about some of the finer points of vim regular expressions
earlier that day, and he knew exactly the trick I needed -- that
.\{72\}, which matches lines that are at least 72
characters long. And amazingly, that expression did something very
close to what I wanted.
Or at least the first step of it. It inserts the first line break,
turning my line into
1020 U22A MS 303 Terrestrial Impact Cratering: New Insights
Into the Cratering Process From Geophysics and Geochemistry II
but I still needed to wrap the second and subsequent lines.
But that was an easier problem -- just do essentially the same thing
again, but limit it to only lines starting with a tab.
After some tweaking, I arrived at exactly what I wanted:
I had to run the second line two or three times to wrap the very long
lines.
Devdas helpfully translated the second one into English:
"You have 3 tabs, followed by 58 characters, out of
which you match the first 55 and put that bit in $1, and the capture
the remaining in $2, and rewrite to $1 newline tab tab tab $2."
Here's a more detailed breakdown:
Line one:
%
Do this over the whole file
s/
Begin global substitute
^
Start at the beginning of the line
\(
Remember the result of the next match
.\{,65\}_
Look for up to 65 characters with a space at the end
\) \(
End of remembered pattern #1, skip a space, and
start remembered pattern #2
.*\)
Pattern #2 includes everything to the end of the line
/
End of matched pattern; begin replacement pattern
\1^M
Insert saved pattern #1 (the first 65 lines ending with a
space) followed by a newline
^I^I^I\2
On the second line, insert three tabs then
saved pattern #2
/
End replacement pattern
Line two:
%g/
Over the whole file, only operate on lines with this pattern
^^I^I^I
Lines starting with three tabs
.\{58\}/
After the tabs, only match lines that still have at
least 58 characters
(this guards against wrapping already wrapped lines
when it's run repeatedly)
s/
Begin global substitute
^
Start at the beginning of the line
\(
Remember the result of the next match
.\{,55\}
Up to 55 characters
\) \(
End of remembered pattern #1, skip a space, and
start remembered pattern #2
.*\)
Pattern #2 includes everything to the end of the line
/
End of matched pattern; begin replacement pattern
\1^M
The first pattern (up to 55 chars) is one line
^I^I^I\2
Three tabs then the second pattern
/
End replacement pattern
Greedy and non-greedy brace matches
The real key is those curly-brace expressions, \{,65\}
and \{58\} -- that's how you control how many characters
vim will match and whether or not the match is "greedy".
Here's how they work (thanks to Mikael for explaining).
The basic expression is {M,N} --
it means between M and N matches of whatever precedes it.
(Vim requires that the first brace be escaped -- \{}. Escaping the
second brace is optional.)
So .{M,N} can match anything between M and N characters
but "prefer" N, i.e. try to match as many as possible up to N.
To make it "non-greedy" (match as few as possible, "preferring" M),
use .{-M,N}
You can leave out M, N, or both; M defaults to 0 while N defaults to
infinity. So {} is short for {0,∞} and is
equivalent to *, while {-} means {-0,∞}, like a non-greedy
version of *.
Given the string: one, two, three, four, five
,.\{},
matches , two, three, four,
,.\{-},
matches , two,
,.\{5,},
matches , two, three, four,
,.\{-5,},
matches , two, three,
,.\{,2},
matches nothing
,.\{,7},
matches , two,
,.\{5,7},
matches , three,
Of course, this syntax is purely for vim; regular expressions are
unfortunately different in sed, perl and every other program.
Here's a fun
table of
regexp terms in various programs.
Looking for a volume control that might me installed on mom's
XFCE4-based Xubuntu desktop, I tried running xfce4-mixer.
The mixer came up fine -- but after I exited, I discovered that
my xchat had gone all wonky. None of my normal key bindings worked,
my cursor was blinking, and the fonts used for tabs was about half its
normal size. Over in my Firefox window, key bindings were also
affected.
I've seen this sort of thing happen before with Gnome apps, and
had found a way to solve it using
gconf-editor. That app was not installed, so I installed it and
discovered that it didn't help.
I tried killing the running gconfd-2, removing .gconf/ and .gconfd/
from my home directory, then removing the four gnome directories
(.gnome/, .gnome2/, .gnome2_private/, and .gnome_private/).
Nothing helped xchat (though Firefox did return to normal).
After much flailing and annoying people by restarting xchat repeatedly,
it turned out the problem was that xfce-mixer had started a daemon
called xfce-mcs-manager, which is like gconf, only
different. Like gconf, it mucks with settings of all running gtk
programs without asking first. It runs simultaneously with gconf,
but overrides gconf, which in turn overrides the values set in
~/.gtkrc-2.0.
Killing xfce-mcs-manager caused my running xchat
to revert to its normal settings.
... Well, *almost* revert. A few key bindings didn't get reset, as
I discovered when I hit a ctrl-W to erase the last word and found
myself disconnected from the channel. Another xchat restart, with
xfce-mcs-manager not running, fixed that.
Aside from the ever-present issue of "Where do I look when some
unfriendly program decides to change the settings in running
applications?" (which begs the question,
"What genius thought it would be a good idea to give any random app
like a volume control the power to change settings in every other
gtk application currently running on the system? And do they have
their medications adjusted better now?")
there's another reason this is interesting.
See, if an arbitrary app like xfce-mcs-manager can send a message to
xchat to change key bindings like ctrl-W ... then maybe I could write
a program that could send a similar message telling xchat to cancel
those compiled-in bindings like ctrl-F and ctrl-L, ones that it doesn't
allow the user to change. If I could get something like that working,
I could use a standard xchat -- I'd no longer need to patch the source
and build my own.
I've been running on Ubuntu's latest, "Gutsy gibbon", for maybe
a month now. Like any release, it has its problems that I've needed to
work around. Like many distros, these problems won't be fixed before
the next release. But unlike other distros, it's not just lack of
developer time; it turns out Ubuntu's developers point to an official
policy as a reason not to fix bugs.
Take the case of the
aumix
bug. Aumix just plain doesn't work in gutsy. It prints,
"aumix: SOUND_MIXER_READ_DEVMASK" and exits.
This turns out to be some error in the way it was compiled.
If you apt-get the official ubuntu sources, build the package
and install it yourself, it works fine. So somehow they got a glitch
during the process of building it, and produced a bad binary.
(Minor digression -- does that make this a GPL violation? Shipping
sources that don't match the distributed binary? No telling what
sources were used to produce the binary in Gutsy. Not that anyone
would actually want the sources for the broken aumix, of course.)
It's an easy fix, right? Just rebuild the binary from the source
in the repository, and push it to the servers.
Apparently not. A few days ago, Henrik Nilsen Omma wrote in the bug:
This bug was nominated for Gutsy but does currently not qualify for a 7.10 stable release update (SRU) and the nomination is therefore declined.
According the the SRU policy, the fix should already be deployed and
tested in the current development version before an update to the
stable releases will be considered. [ ... ]
See: https://wiki.ubuntu.com/StableReleaseUpdates.
Of course, I clicked on the link to receive enlightenment.
Ubuntu's Stable Release page explains
Users of the official release, in contrast, expect a high degree of
stability. They use their Ubuntu system for their day-to-day work, and
problems they experience with it can be extremely disruptive. Many of
them are less experienced with Ubuntu and with Linux, and expect a
reliable system which does not require their intervention.
by way of explaining the official Ubuntu policy on updates:
Stable release updates will, in general, only be issued in order to
fix high-impact bugs. Examples of such bugs include:
Bugs which may, under realistic circumstances, directly cause a
security vulnerability
Bugs which represent severe regressions from the previous release of Ubuntu
Bugs which may, under realistic circumstances, directly cause a
loss of user data
Clearly aumix isn't a security vulnerability or a loss of user data.
But I could make a good argument that a package that doesn't work ...
ever ... for anyone ... constitutes a severe regression from
the previous version of that package.
Ubuntu apparently thinks that users get used to packages not working,
and grow to like it. I guess that if you actually fixed
packages that you broke, that would be disruptive to users of the
stable release.
I'm trying to picture these Ubuntu target users, who embrace
regressions and get upset when something that doesn't work at all gets
fixed so that it works as it did in past releases. I can't say I've
ever actually met a user like that myself. But evidently the Ubuntu
Updates Team knows better.
Update: I just have to pass along Dave's comment:
"When an organization gets to the point where it spends more energy
on institutional processes for justifying not fixing
something than on just fixing it -- it's over."
I bought a new bottle of shampoo. Like many shampoos, its label tries to
promote it as a natural, healthy alternative for natural, healthy
hair. To this end, it proclaims that it's "enriched with orange
fruit extract and provitamin B5".
Leaving aside the question of "What's provitamin B5 and why should it
be good to rub it on the outside of a dead keratin layer?", I like
the colorful, natural, healthy looking picture on the front of the
bottle.
The picture shows two halves of a sliced orange; a wedge of lime;
and ... a watermelon?
Now, I know I'm not a botanist, but somehow I'd been unaware up
to now that watermelon was a citrus fruit.
Amazing what you can learn simply from browsing the supermarket aisles!
With what I learned
last week,
I've been able to type accented characters into GTK apps such as xchat,
and a few other apps such as emacs.
That's nice -- but I was still having trouble reading accented
characters in mutt, or writing them in vim to send through mutt
(darn terminal apps).
The biggest problem was the terminal. I was using urxvt,
but it turns out that urxvt won't let me type any nonascii characters.
It just ignores my multi-key sequences, or prints a space instead
of the character I wanted.
I have no idea why, but switching to plain ol' xterm solved that problem.
Of course, I had to make sure that I was using a font that supported
the characters I wanted (ISO 8859-1 or 8859-15 or something similar),
which leaves out my favorite terminal font (Schumacher Clean bold),
but Bitstream Vera Sans Mono bold is almost as readable.
Of course, it's important to have your locale variables set
appropriately. There are several locale variables:
LC_CTYPE
Which encodings to use for typing and displaying characters.
LC_MESSAGES
Which translations to use, in programs that offer them.
LC_COLLATE
How to sort alphabetically (this one also affects whether ls
groups capitalized filenames first).
LC_ALL
Overrides any of the others.
LANG
The default, in case none of the other variables is set.
There are a few others which control very specific features like
time, numbers, money, addresses and paper size:
type locale to see all of them.
Once I switched to xterm, I was able to set either LANG or LC_CTYPE to
either en_US.UTF-8 or en_US.ISO-8859-1.
I set LC_COLLATE and LANG or LC_MESSAGES to C, so that I get the
default (usually US) translations for programs and so that ls groups
all the capitalized files first.
Along the way, I learned about yet another
way to type accented characters.
setxkbmap -model pc104 -layout us -variant intl
switches to an international layout, at which point typing certain
punctuation (like ' or ~) is assumed to be a prefix key. So instead
of typing [Multi] ~ n, I can just type ~ n. The catch: it makes it
harder to type quotes or tildes by themselves (you have to type a
space after the quote or tilde).
Even faster, the international layout also offers shortcuts to many
common characters with the "AltGr" key, which I'd heard about
for years but never knew how to enable. AltGr is the right alt
key, and typing, say, AltGr followed by n gives an ñ.
You can see a full map at
Wikipedia
(AltGr characters are blue, quote prefixes are red).
To get back to a US non-international layout:
setxkbmap -model pc104 -layout us
Of course, these aren't the only keyboard layouts to choose from --
there are lots, plus you can define your own. And I was going to
write a little bit about that, except it turns out they've changed
it all around again since I last did that two years ago (don't you
love the digital world?). So that will have to wait for another time.
But the place to start exploring is /usr/share/X11/xkb.
The file symbols/us contains the definitions for those US
keyboards, and I believe it's included via the files in the
rules directory, probably rules/base, base.xml and base.lst.
From there you're on your own. But the standard layouts probably
follow the ones in the Wikipedia article on
keyboard layouts
I upgraded my system to the latest Ubuntu, "Gutsy Gibbon", recently.
Of course, it's always best
to make a backup before doing a major upgrade. In this case, the goal
was to back up my root partition to another partition on the same
disk and get it working as a bootable Ubuntu, which I could then
upgrade, saving the old partition as a working backup.
I'll describe here a couple of silly snags I hit,
to save you from making the same mistakes.
Linux offers lots of ways to copy filesystems.
I've used tar in the past, with a command like (starting in /gutsy):
tar --one-file-system -cf - / | tar xvf - > /tmp/backup.out
but cp seemed like an easier way, so I want to try it.
I mounted my freshly made backup partition as /gutsy and started a
cp -ax /* /gutsy (-a does the right thing for
permissions, owner and group, and file type; -x tells it to stay
on the original filesystem).
Count to ten, then check what's getting copied.
Whoops! It clearly wasn't staying on the original filesystem.
It turned out my mistake was that /*.
Pretty obvious in hindsight what cp was doing: for each entry in /
it did a cp -ax, staying on the filesystem for that entry, not on
the filesystem for /. So /home, /boot, /proc, etc. all got copied.
The solution was to remove the *: cp -ax / /gutsy.
But it wasn't quite that simple.
It looked like it was working -- a long wait, then cp finished
and I had what looked like a nice filesystem backup.
I adjusted /gutsy/etc/fstab so that it would point to the right root,
set up a grub entry, and rebooted. Disaster! The boot hung right after
Attached scsi generic sg0 type 0 with no indication of
what was wrong.
Rebooting into the old partition told me that what's supposed to
happen next is: * Setting preliminary keymap...
But the crucial error message was actually
several lines earlier: Warning: unable to open an initial
console. It hadn't been able to open /dev/console.
Now, in the newly copied filesystem,
there was no /dev/console: in fact, /dev was empty. Nothing had been
copied because /dev is a virtual file system, created by udev.
But it turns out that the boot process needs some static devices in
/dev, before udev has created anything. Of course, once udev's
virtual filesystem has been mounted on /dev, you can no longer read
whatever was in /dev on the root partition in order to copy it
somewhere else. But udev nicely gives you access to it,
in /dev/.static/dev. So what I needed to do to get my new partition
booting was:
cp -ax /dev/.static/dev/ /gutsy/dev/
With that done, I was able to boot into my new filesystem and upgrade
to Gutsy.
Happy Thanksgiving, everyone! Today's holiday tip involves
how to type international characters.
For the online Spanish class I've been taking, so far I've been
able to manage without having to type characters like
ñ or á. Usually, if I need one I can find it in one of
the class examples, copy it, and paste it wherever I need it. But
obviously that would be tedious if I needed to type much.
I hacked up a quickie workaround:
a python
script that shows a set of buttons, one for each accented
character I'm likely to need. Clicking a button copies that character
to the clipboard, so I can now paste via mouse middleclick or ctrl-V.
(I'm sure that sounds pathetic to those of you who type accented
characters every day, but it's not something most US English speakers
need to do. And besides, now I know how to access the X clipboard
from Python-GTK -- hooray for learning new things from procrastination
projects!)
Anyway, Mikael Magnusson took pity on me and explained in simple
language how to use the X "Multi key"
(Update: more commonly called the "Compose key")
to type these characters the
right way (well, a right way, anyway). Since all the online
instructions I've seen have been rather complicated, here are the
simple instructions for any of my fellow US monolinguists who'd
like to expand their horizons:
First, choose a key for the "Multi key" that you're not using for
anything else. A lot of people use one of the Alt or Windows keys,
but I use both of those already. What I don't use is the Menu key
(that little key down by the right Ctrl key, at least on my keyboard)
since not many Linux apps support it anyway.
Find the keycode for that key, by firing up xev and
typing the key. For my Menu key, the keycode is 117.
Now type:
xmodmap -e "keycode 117 = Multi_key"
Update, 2025:
xmodmap probably still works, but on Debian-based systems I prefer to
set the Compose key via /etc/default/keyboard, where I add a
line like this:
The ctrl:nocaps is unrelated: it makes the Caps Lock key act
like a Control key, so you can type control sequences like the
emacs/readline bindings without moving your left hand from the home position.
After changing /etc/default/keyboard, run this as root:
Now you're ready to type a sequence like:
[Menu] ~ n
to type an n-tilde,
[Menu] ' a
for an accented a, or
[menu] ? ? for the upside-down question mark,
in any app that supports those characters.
Of course, you don't want to type that xmodmap command every time you
log in, so to make it permanent, put this in your .Xmodmap (you're on
your own for figuring out whether your X environment reads .Xmodmap
automatically or whether you need to tell it to run
xmodmap .Xmodmap when X starts up):
keycode 117 = Multi_key
I have one final useful international input tidbit to offer:
how to type Unicode characters by number.
Hold ctrl+shift+U, then release U but keep holding the
other two while you type a numeric sequence. (This may only work in
gtk apps.) For instance, try this: hold down ctrl and shift, then
type: u 2 6 6 c. Cool, huh?
You can use the "gucharmap" program to find other
neat sequences (hint: View->By Unicode Block otherwise
you'll never find anything).
Now it's time to check the turkey. Have a good day, everyone!
We found a tiny baby newt struggling its way across the Zinfandel
trail at Stevens Creek.
Really across the trail -- I didn't see it and might have stepped
on it, but luck was with both of us. Dave spotted it after I passed.
We stopped to admire, handle and photograph it, then set it gently
off the trail so it could continue to struggle its way up the hill.
(Then rinsed our hands thoroughly -- rough-skinned newts and their
cousins the California newts secrete a strong neurotoxin through
their skin. It's only dangerous if you eat it.
They have an interesting defensive posture -- which I've only seen
in books and
on the web
-- showing bright colors to let an attacker know they're poisonous.
Garter snakes are the only predator resistant to the toxin.)
I don't know what's at the top of the hill that's so attractive for
a young newt, but evidently it's worth some effort. I hope this
little one makes it there.
I can't stop thinking about the woman in the Chinese restaurant the
other night.
It was one of those conversations you try not to overhear, but they're
so loud and distracting that you just can't avoid it.
In the middle of a long declamation on conspiracy theories and
politics, the man made a comment about how we're in the middle
east shooting Iraqis who never hurt anyone. (I didn't say his politics
were all wrong, just loud).
The woman, who had been relatively quiet up to now, interrupted,
"But they hurt us in 9/11!"
In the next booth, facing away from them, my mouth dropped open.
The man quickly countered that Iraq had nothing to do with 9/11,
but then was off onto other topics, sharing with the room his
theories on war in the middle east in general, Israel, and people
trying to wipe out the Jews. This caught the woman's interest --
"They already tried that, Hitler." After a pause, she added
thoughtfully, "You know, the strangest thing about that is how
people there just went along with it."
That came barely a minute after the 9/11 comment.
She clearly had no idea of the irony of juxtaposing the two.
I wanted to turn around and say, "Perhaps they went along for the same
reason that you're going along with killing hundreds of thousands of
Iraqi civilians, when even the president who started the war admits
that Iraq had nothing to do with 9/11?"
I spent a couple of fruitless hours today trying to install PCLinuxOS,
a well-reviewed new Linux distro, on my Vaio. I got lots of help
from the nice folks on the IRC channel, and tried lots of different
approaches, but no dice -- their Live CD won't boot because it doesn't
grok PCMCIA CDROM drives, and they have no other installation method
besides using the live CD.
Which brings me to today's question:
Why do Linux distros have installers at all?
That probably sounds like a silly question. Of course you need an
installer to get the system onto your disk ... don't you?
Well, yes and no. You could make it a lot simpler than anyone
currently does.
What if you distributed a Linux distro as a filesystem image?
Make it tar, zip, CD iso or whatever format you like -- but
provide the user with a tree of files that, when copied onto a
hard drive, can boot as a running Linux.
Set up this minimal installation filesystem so that when you boot
into it, you get a commandline (X hasn't been configured yet)
and a set of scripts that make it easy to go the rest of the way.
From your running minimal system, you can configure X, set up
networking, install more programs from the distro repositories (or
even from a CD image), and do all the rest of the machine-specific
configuration that an installer does.
The key is that this is all happening from a running system,
not from some cobbled-together installer kernel or live CD.
If you have a problem with any step, you still have a basic
running system, and tools to fix the problem. You avoid the
usual loop:
Run installer
Spend 20 minutes answering questions
Spend 45 minutes waiting for installer
Discover it failed
Start over with slightly different parameters
If your X configuration fails, try running X configuration again --
no need to do another install from the beginning. If it doesn't
see your network card -- ditto. Since this debugging all happens
from a normal running Linux, you can use the normal Linux tools you're
used to, not some busybox-based installer.
This model would be much more hardware agnostic than current installers:
You can install on systems with weirdo graphics cards;
You can install on systems that need special drivers for the
network card or other hardware;
You can install on systems with no CDROM or an external CDROM;
You can install even if you don't have access to a CD burner.
Another advantage is that it makes it very easy to
make a customized version of your distro: just take the basic
system image, change the part that needs changing and tar it up again.
Some distros have gone a little way with this, with an installer
that gives you a starter system, then scripts to download the
rest -- but I've never seen one that made the minimal system
available as a filesystem image, with easy instructions on going
to the next step.
What about the people who aren't already running Linux or aren't
comfortable writing a filesystem image to a partition?
No problem. They get a CD image with a very simple installer --
it handles the partitioning, copies the minimal install to the
partition, and updates grub. It's as prone to hardware compatibility
issues as any installer (though far less so than a live CD is)
but it's still better than the current model, because it won't be
trying to configure hardware until the user reboots into a working
minimal system.
Of course, Live CDs are still cool -- on machines where they
actually work -- for showing Linux to people not ready to commit
to an install. But don't tie your installer to that. Give people
a simpler way to install, one that's fast and straightforward and
hardware agnostic and easy to understand or customize.
The tarball installer. An idea whose time has come.
Now if I could just persuade the distros to offer it.
Update: a couple of people told me about
Dynebolic, a distro that
apparently does just that -- you install by copying a directory
on the CD onto your partition, or rsyncing from their site. Nice!
Something rustled madly in the star jasmine when I walked past.
Probably just a sparrow, I thought. Ever since the sparrows discovered
the squirrel nuts, there's been a gang camped out in the guava tree
just outside the office door at all times.
I put it out of my mind until an hour later, when Dave reported,
"There's an orphan squirrel in the star jasmine. It looks too small to
be out on its own. Where is its mother?"
We put a few pieces of walnut out by the bush and watched.
After a little while the youngster came out to
investigate, moving very slowly and awkwardly,
and sat next to the walnut pieces. It didn't sit normally:
its weight was back on its tail, with hind legs stuck out in
front and crossed, like a tiny squirrel Buddha.
The tiny youngster took a piece of walnut in its front paws and stared
at it blankly as if wondering what to do with it. But ten minutes later
we saw that it was nibbling, slowly and tentatively. It took a long
time, but the orphan eventually made it through three pieces of walnut.
We provided more walnut (the fearful youngster scurried back under the
jasmine) and a little dish of water and waited, but the orphan didn't
reappear. An hour later, we saw a small young squirrel climbing a tree
in the front yard. Could it be the same one? The baby we'd seen didn't
look capable of climbing anything. Could it have been merely weak from
hunger and fear, and a few nuts revived it?
The next morning, a new squirrel appeared at our feeding area in
the backyard. A young female, small but confident. She was able to
move both up and down fenceposts and leap from the fence to the
oak tree, usually difficult maneuvers for a squirrel trainee.
Surely this couldn't be the same tiny, shivering orphan we'd seen
the day before?
But after finding a nut I'd left on the fence, this youngster sat in
the same odd Buddha fashion to eat it.
Little orphan Annie turned out to be smart as well as agile.
She caught on to the nut shelf early -- she was hanging out in the
guava (whose springy branches make a great playground for a light
little squirreling) when a mouse made a rare appearance, darting
out from under the deck to the nut shelf to grab a nut and run back
to its hole. I could see Annie's head move as she watched the mouse;
I could almost imagine her eyes widening. No need to tell her twice!
She was down the guava and over to the nut shelf like a flash
to pick up a piece for herself.
Annie hung around for about a week after that (getting chased by
Ringtail a few times) but then she stopped visiting. Life is tough
for young squirrels. I hope Annie's all right, and just moved on to
find a nuttier place to live.
I've been a tcsh user for many years. Back in the day, there were lots
of reasons for preferring csh to sh, mostly having to do with command
history. Most of those reasons are long gone -- modern bash and
tcsh are vastly improved from those early shells, and borrow from each
other, so the differences are fairly minor.
Back in July, I solved
the last blocker that had been keeping me off bash,
so I put some effort into migrating all my .cshrc settings into
a .bashrc so I could give bash a fair shot. It almost won; but
after four months, I've switched back to tcsh, due mostly to a single
niggling bash bug that I just can't seem to solve.
After all these years, the crucial difference is still history.
Specifically, history amnesia: bash has an annoying habit of
forgetting history commands just when I most want them back.
Say I type some longish command.
After it runs, I hit return a couple of times, wait a while, do
a couple of other things, then decide I want to call that command
back from history so I can run something similar, maybe with the
filename changed or a different flag. I ctrl-P or up-arrow ... and
the command isn't there!
If I type history at this point, I'll see most of my
command history ... with an empty line in place of the line I was
hoping to repeat. The command is gone. My only option is to remember
what I typed, and type it all again.
Nobody seems to know why this happens, and it's sporadic, doesn't
happen every time. Friends have been able to reproduce it, so it's
not just me or my weird settings. It drives me batty.
It wouldn't be so bad except it always seems to happen on the
tricky commands that I really didn't want to retype.
It's too bad, because otherwise I had bash nicely whipped into shape,
and it does have some advantages over tcsh. Some of the tradeoffs:
tcsh wins
Totally reliable history: commands never disappear.
History tab completion: typing !a<TAB>
expands to the last command that started with a. In bash, I have
to type !a:p to see the command, then
!! to execute it.
When I tab-complete a file and there are multiple matches, tcsh shows
them, or at least beeps (depending on configuration). In bash I have
to hit a second tab just in case there might be matches.
When I tab-complete a directory, tcsh adds the / automatically.
(Arguable. I find I want the / roughly 3/4 of the time.)
tcsh doesn't drop remote connections if I suspend (with ~^Z).
bash drops me within a minute or two, regardless of settings like
$TMOUT. Bash users tell me I could solve this by using screen,
but that seems like a heavyweight workaround when tcsh "just works".
tcsh sees $REMOTEHOST and $DISPLAY automatically when I ssh.
bash doesn't: ssh -X helps, but I still need some tricky
code in .bash_profile.
aliases can have arguments, e.g.
alias llth 'ls -laFt \!* | head'
In bash these have to be functions, which means they don't show
up typing "which" or "alias".
Prompt settings are more flexible -- there are options like %B for
bold. In bash you have to get the terminal type and use the
ansi color escape sequances, which don't include bold.
Easier command editing setup -- behaviors like
getting
word-erase to stop at punctuation
don't involve chasing through multiple semi-documented programs,
and the answer doesn't vary with version.
Documentation -- tcsh's is mostly in man tcsh, bash's is
scattered all over man pages for various helper programs.
And it's hard to google for bash help because "bash" as a keyword
gets you lots of stuff not related to shells.
Of course, you bash users, set me straight if I missed out
on some bash options that would have solved some of these problems.
And especially if you have a clue about the evil disappearing
history commands!
bash wins
You don't have to rehash every time you add a program
or change your path. That's a real annoyance of tcsh, and I could
understand a person used to bash rejecting tcsh on this alone.
Update: Holger Weiß has written
a tcsh patch to fix this, and it has been accepted as of
November 2009. Looking forward to the next version!
History remembers entire multi-line commands, and shows them
with semicolons when you arrow back through history. Very nice.
tcsh only remembers the first line and you have to retype the rest.
Functions: although I don't like having to use them instead of
aliases, they're certainly powerful and nice to have.
Of course, bash and tcsh aren't the only shells around.
From what I hear, zsh blends the good features of bash and tcsh.
One of these days I'll try it and see.
I finally got a chance to take a look at Comet 17/P Holmes.
I'd been hearing about this bright comet for a couple of days, since
it unexpectedly broke up and flared from about 17th magnitude (fainter
than most amateur telescopes can pick up even in dark skies) to 2nd
magnitude (easily visible to the naked eye from light-polluted
cities). It's in Perseus, so only visible from the northern
hemisphere, pretty much any time after dark (but it's higher
a little later in the evening).
And it's just as bright as advertised. I grabbed my binoculars, used a
finder chart
posted by one of our local SJAA members,
and there it was, bright and obviously fuzzy. Without the binoculars
it was still easy to see, and still noticably fuzzy.
So I dragged out the trusty 6" dobsonian, and although it has no
visible tail, it has lots of structure. It looked like this:
It has a stellar nucleus, a bright inner area (the coma?) and a
much larger, fainter outer halo. There's also a faint star just
outside the coma, so it'll be fun (if we continue to get holes in
the clouds) to see how fast it moves relative to that star.
(Not much motion in the past hour.)
It's nice to have a bright comet in the sky again! Anyone interested
in astronomy should check this one out in the next few days -- since
it may be in the process of breaking up, there's no telling how long
it'll last or what will happen next. Grab some binoculars, or a 'scope
if you have one, and take a look.
I'm sitting here at my desk, taking a break from homework and listening
to the plop, plop of guavas falling from the tree outside my
window.
Both trees are going pretty crazy this year.
Big, ripe, tasty guavas accumulate way faster than I can eat them.
I should probably learn how to make jam, but it always sounds so daunting.
And this year the squirrels aren't interested (funny, since last
fall's squirrels liked guavas quite a lot).
Gathering the guavas always reminds me of hunting easter eggs.
They fall into the tall sorrel, or the branchlets sprouting from
the bottom of the bigger guava tree, or into the tangled, fragrant
mess of lantana that pokes its head around the corner and under
the tree. Guavas are smaller than easter eggs and not as colorful,
but they're about the same shape ... and the thrill of discovery
when you spot that elusive green fruit hiding in the underbrush
is a lot like what I remember from those long-ago easter egg hunts.
I just heard another plop. I think I'll go eat a guava.
I just got back from She's Geeky.
What a rush! It'll take me a while to wind down from this fabulous
all-women meeting.
I have to admit, I was initially dubious. A conference for geeky women
sounded great, but it struck me as kind of
expensive -- $175 (with a $125 early-bird rate). That's very cheap
as tech conferences go, but for a two-day "unconference", it was
enough to turn off most local techie women I know: nearly all of them
knew about She's Geeky and said "I'd love to go but I can't afford
it." Full disclosure: I said the same thing, and wouldn't have gone
myself had I not gotten a "scholarship", for which I am immensely grateful.
(In retrospect, considering how well run it was, it probably
would have been worth the early-bird price. But that's not easy
to tell ahead of time.)
Monday consisted of lunch and informal discussion followed by
two sessions of scheduled talks. I particularly liked the afternoon
schedule, which included two different sessions of speaker training:
the theory being that one factor holding women back in technology
jobs is that we don't make ourselves visible by public speaking
as much as we could. I went to the "Lightening (sic) Talks" session,
headed by Danese Cooper. It didn't make me lighter, but we got some
great advice at giving conference talks (lightning and otherwise)
plus two rounds of practice at three minute talks.
I'm not sure what I enjoyed more, the practice and useful feedback or
the chance to listen to so many great short talks on disparate and
interesting subjects.
Tuesday started way before normal geek time, with bagels and espresso
and an explanation by conference organizer Kaliya Hamlin on how we'd
use the Open Space process.
Sessions would be an hour long, and we had eight rooms to work with,
all charted on a huge grid on the wall. Anyone could run a session
(or several). Write it (and your name) on a card, get up and tell the
group about it, then find a time and space for it and tape it on
the grid. Rules for sessions were few.
For session leaders, Whoever comes to your session is the right
audience, and whatever happens is what should have happened.
For people attending a session there's the Rule of Two Feet:
if you're not getting anything out of the session you're in,
you should get up and get yourself to somewhere where
you're contributing and/or learning. Not hard when there are seven
other sessions to choose from.
This all worked exactly as described. Whatever hesitance many
women may feel toward public speaking, there was no lack of volunteer
session leaders on a wide variety of topics, both technical and social.
I signed up to give a GIMP session before lunch; then in a morning
session on server and firewall configuration given by fellow
LinuxChix Gloria W. and Gaba,
I noticed a few people having a lot of general Linux questions,
in particular command-line questions, so I ran back to the wall
grid and added an afternoon session on "Understanding the Linux
command line".
Easily my favorite session of the conference was the Google Maps API
talk by Pamela Fox of Google. I've been meaning to experiment
with Google Maps and KML for a long time. I even have books on it
sitting on my shelf. But I never seem to get over the hump: find a
project and a specific task, then go
RTFM
and figure out how to write
a KML file from scratch to do something fun and useful. Pamela got
me over that in a hurry -- she showed us the "My Maps" tab in
Google Maps (you have to be signed on to a Google account to use
it). It includes tools for generating some starter KML
interactively, and it even has a polygon editor, all implemented
in AJAX (Javascript) and running in a browser. Wow! What a great
way to get a running start on map mashups. There's also a whole open
source Javascript API and set of libraries for writing creative web
mapping apps. I'm sure I'll be experimenting with this a lot more
and writing about it separately. Just this talk alone made the
conference worthwhile, even without all the other great sessions.
But I didn't get a chance to experiment right away with any of
that cool mapping stuff, because right after that session was
one by speaker and comedian Heather
Gold. Heather had given Saturday night's evening entertainment,
and I am very sorry to have had to miss the show to go to a night class.
The session was on self confidence, getting over fear of speaking,
and connecting with the audience. Since the allotted space was noisy
(the same one I'd ended up with for my GIMP talk, and the noise was
definitely a problem), Heather led our small group out onto the
balcony to enjoy the warm weather. The group was diverse and included
women at very different levels of speaking, but Heather had great tips
for all of us. She has great presence and a lot of useful things to
say, and she's funny -- I'd love to see her on stage.
Everybody had a really positive attitude.
At the Lightning Talks session on Saturday, Danese stressed
"No whinging" as a general rule to follow (in talks or anywhere else),
and I'd say the whole conference followed it.
While we heard about lots of serious topics women face, I
didn't hear any whining or "men are keeping us down" or that sort
of negativism. There were some bad experiences shared as well as good
ones, but the point was in finding solutions and making progress, not
dwelling on problems. This was a group of women doing things.
There are only two changes I can think of that could have improved the
conference at all.
First, I already mentioned the cost. While it was fair
considering the fantastic organization, great people, plus catered
meals, it still lets out some of the women who could have benefitted the
most: students and the un- and under-employed. A few of us LinuxChix
talked about how much we'd love to see a similar conference held at
a cheaper facility, without the handouts or the catered meals.
Maybe some day we'll be able to make it happen.
Second (and this is a very minor point), it might have been helpful
to have runners reminding people when sessions were ending, and
perhaps making the sessions 55 minutes instead of an hour to encourage
getting to the next session and starting on promptly.
Even without that, people mostly stuck to the schedule and Tuesday
finished right on time: pretty amazing for a conference whose agenda
had been made that morning with cardboard, tape and marking pens.
I've seen unconferences before, and they're usually a disorganized mess.
This one ran better than most scheduled conferences. Kaliya and her
fellow organizers clearly know how to make this process work.
We all pitched in to clean up the room, and I braved the rush-hour
freeway.
And arrived home to find that my husband had cooked dinner and it
was just about ready.
What a nice ending to the day!
I'm taking an online Spanish class. My mom talked me into it -- she
and I both periodically try to learn Spanish, then forget it again
because we don't practice enough. The hope is that if we're both
taking the same class, we'll converse with each other by email
en Español, have more fun and learn better.
I have no particular talent for (non-computer) languages,
and in particular I have trouble learning vocabulary. By Lesson 2
I could see already that I was going to have trouble with the
vocabulary lists. What I needed was flash cards!
There are probably a bazillion flash card apps around. But it's
such a trivial problem, why not re-invent the wheel for the
bazillion-and-oneth time? It's more fun to spend an hour hacking
Python than to spend an hour googling and tossing out all the Windows
and Mac and Java and web oriented solutions looking for something
that's small, self-contained and runs on Linux.
So ... my trivial flashcard in
Python. It doesn't make you type in the answer -- you just think
of the answer and hit return, and if you got it right, hit return
again for the next word. If you got it wrong, type something else
(. or space or x or whatever) followed by return, and it'll remember
that you got it wrong, increase the liklihood of showing you that
word again, and print a list of words missed at the end (when you
type q to quit).
I needed the
# -*- coding: utf-8 -*-
at the beginning to keep it from complaining about the various
accented characters in some of the Spanish words, but that doesn't
automatically make it print those characters correctly. With LANG=C,
it translates them into plain ASCII, which is okay with me most of
the time. With LANG=en_US.UTF-8, which you'd think would work,
it tends to print garbage characters or hexadecimal codes -- not so
okay. The trick turns out to be to set it to Spanish:
export LANG=es_ES.UTF-8
Perhaps I can force that in the script. But not right now ...
I'm off to She's Geeky,
a conference on Women in Tech going on in Mountain View today and
tomorrow.
Tags: education
[ 12:45 Oct 22, 2007
More education |
permalink to this entry |
]
I ran out of business cards (where do they go? I never seem to find
occasion to give any out. They make good bookmarks, though) and
wanted to print some more. I use gLabels for low-res label printing,
but it prints poorly (or used to, anyway) so when I want something
with crisp and sharp images, I use GIMP with my
GIMP Labels
script.
That's all fine, except that the "make label page" part of the script
scales the labels to fit on a typical Avery letter-sized template --
and the Gutenprint drivers for my printer can't actually fill a
letter sized page. (I have the choice of normal printing, in which
it fills about 97% of the page, or Borderless printing, where it
slops way over the edges.)
The solution is to crop a little extra off the outside edge of the
label page. So I added some code to script-fu-rect-label-page to
keep a "Printer fudge factor" and crop the page at the end.
An easy tweak which seems to work fine, and with any luck it'll
cure a lot of the misalignment problems I've seen with labels.
While I was making changes anyway, I added some clearer installation
instructions for the 95% case of someone who just wants the script
with the labels I've included, since I recently heard from someone who
wasn't clear on where to install the script.
I remember a few years ago the Mozilla folks were making a lot of
noise about the "blazingly fast Back/Forward" that was coming up
in the (then) next version of Firefox. The idea was that the layout
engine was going to remember how the page was laid out (technically,
there would be a "frame cache" as opposed to the normal cache which
only remembers the HTML of the page). So when you click the Back
button, Firefox would remember everything it knew about that page --
it wouldn't have to parse the HTML again or figure out how to lay
out all those tables and images, it would just instantly display
what the page looked like last time.
Time passed ... and Back/Forward didn't get faster. In fact, they
got a lot slower. The "Blazingly Fast Back" code did get checked in
(here's
how to enable it)
but somehow it never seemed to make any difference.
The problem, it turns out, is that the landing of
bug
101832 added code to respect a couple of HTTP Cache-Control header
settings, no-store and no-cache. There's also a
third cache control header, must-revalidate, which is similar
(the difference among the three settings is fairly subtle, and
Firefox seems to treat them pretty much the same way).
Translated, that means that web servers, when they send you a page,
can send some information along with the page that asks the browser
"Please don't keep a local copy of this page -- any time you want
it again, go back to the web and get a new copy."
There are pages for which this makes sense. Consider a secure bank
site. You log in, you do your banking, you view your balance and other
details, you log out and go to lunch ... then someone else comes by
and clicks Back on your browser and can now see all those bank
pages you were just viewing. That's why banks like to set no-cache
headers.
But those are secure pages (https, not http). There are probably
reasons for some non-secure pages to use no-cache or no-store
... um ... I can't think of any offhand, but I'm sure there are some.
But for most pages it's just silly. If I click Back, why wouldn't I
want to go back to the exact same page I was just looking at?
Why would I want to wait for it to reload everything from the server?
The problem is that modern Content Management Systems (CMSes) almost
always set one or more of these headers. Consider the
Linux.conf.au site.
Linx.conf.au is one of the most clueful, geeky conferences around.
Yet the software running their site sets
on every page. I'm sure this isn't intentional -- it makes no sense for
a bunch of basically static pages showing information about a
conference several months away. Drupal, the CMS used by LinuxChix sets
Cache-Control: must-revalidate -- again, pointless.
All it does is make you afraid to click on links because then
if you want to go Back it'll take forever. (I asked some Drupal
folks about this and they said it could be changed with drupal_set_header).
(By the way, you can check the http headers on any page with:
wget -S -O /dev/null http://... or, if you have curl,
curl --head http://...)
Here's an excellent summary of the options in an
Opera developer's
blog, explaining why the way Firefox handle caching is not only
unfriendly to the user, but also wrong according to the specs.
(Darn it, reading sensible articles like that make me wish I wasn't
so deeply invested in Mozilla technology -- Opera cares so much
more about the user experience.)
But, short of a switch to Opera, how could I fix it on my end?
Google wasn't any help, but I figured that this must be a reported
Mozilla bug, so I turned to Bugzilla and found quite a lot.
Here's the scoop. First, the code to respect the cache settings
(slowing down Back/Forward) was apparently added in response to bug 101832.
People quickly noticed the performance problem, and filed
112564.
(This was back in late 2001.) There was a long debate,
but in the end, a fix was checked in which allowed no-cache http
(non-secure) sites to cache and get a fast Back/Forward.
This didn't help no-store and must-revalidate sites, which
were still just as slow as ever.
Then a few months later,
bug
135289 changed this code around quite a bit. I'm still getting
my head around the code involved in the two bugs, but I think this
update didn't change the basic rules governing which
pages get revalidated.
(Warning: geekage alert for next two paragraphs.
Use this fix at your own risk, etc.)
Unfortunately, it looks like the only way to fix this is in the
C++ code. For folks not afraid of building Firefox, the code lives in
nsDocShell::ShouldDiscardLayoutState and controls the no-cache and
no-store directives. In nsDocShell::ShouldDiscardLayoutState
(currently lie 8224, but don't count on it), the final line is:
return (noStore || (noCache && securityInfo));
Change that to
return ((noStore || noCache) && securityInfo);
and Back/Forward will get instantly faster, while still preserving
security for https. (If you don't care about that security issue
and want pages to cache no matter what, just replace the whole
function with return PR_FALSE; )
The must-validate setting is handled in a completely different
place, in nsHttpChannel.
However, for some reason, fixing nsDocShell also fixes Drupal pages
which set only must-validate. I don't quite understand why yet.
More study required.
(End geekage.)
Any Mozilla folks are welcome to tell me why I shouldn't be doing
this, or if there's a better way (especially if it's possible in a
way that would work from an extension or preference).
I'd also be interested in from Drupal or other CMS folks defending why
so many CMSes destroy the user experience like this. But please first
read the Opera article referenced above, so that you understand why I
and so many other users have complained about it. I'm happy to share
any comments I receive (let me know if you want your comments to
be public or not).
On an afternoon hike at Rancho San Antonio, a bright yellow
twice-folded paper caught my eye from the ground beside the
trail.
It began:
ESCI 19 (Martinez, Gorsuch, Poffenroth & Higgins)
FALL 2007
October 19-20 DIABLO RANGE Overnight Field Trip Schedule
37th parallel field studies
then continued with details of the class camping trip to Grant Ranch
county park this weekend.
They're doing a pre-dinner hike, a night lecture, a night hike,
then the next day they have early morning bird-watching and a
morning hike before dispersing.
At the bottom are some
Discussion Questions
1. What environmental issues face California? Bay Area?
2. What will the Bay Area look like in 10 years? 20 years?
Half a mile down the trail, there was another copy: again, twice
folded; again, lying in the dirt by the side of the trail.
I think I have a guess at the answer to Discussion Question 2.
If even Environmental Science students think it's appropriate to toss
their field trip planning sheets any old place on a trail, ten
years from now the Bay Area is going to be buried in paper and
other debris. (Well, at least paper is biodegradeable, unlike candy
wrappers and soda bottles.)
Perhaps Martinez, Gorsuch, Poffenroth & Higgins should consider,
next semester, including a lecture on litter and Leaving No Trace.
(Though it's sad to think that it should be needed, even in a
community college course like this appears to be.)
Last week, one of my favorite science podcasts,
This Week in Science,
had an interview with Danica McKellar. You may remember Danica --
she's written a book for middle school girls called Math
Doesn't Suck: How to Survive Middle-School Math Without Losing Your
Mind or Breaking a Nail. You may also know her as Winnie Cooper
from the old TV show The Wonder Years, or more recently on
West Wing, and she's also a math graduate and co-author of
the Chayes-McKellar-Winn theorem.
Anyway, the interview is great for anyone interested in the general
question of math education. They get into questions like "Why study
math?" and "Why do people find word problems so hard?"
She talks about a survey she passed out to middle school girls while
she was working on the book. Some of the questions had to do with what
they thought of smart girls and dumb girls, and on the latter, the
most common answer was "There are no dumb girls -- they're just
pretending to be dumb."
She was shocked by that. If you play dumb, she tells girls, you'll
get into the habit. If you play dumb to get that guy, you'll have
to keep playing dumb to keep him, and it'll become more and more ingrained.
Eventually you'll start believing it. You'll feel worse and worse
about yourself and you might not even realize why. And stopping it
later might be a lot harder than you think.
She had a great analogy about that from her days on The Wonder
Years. One episode involved people teasing her character for being
a goody-two-shoes, and in particular her good posture. She read the
script and was mortified -- "I do sit straighter than everybody
else! Oh, no! I'm not cool! I should slump more!" She practiced for
weeks, sitting hunched over in the cafeteria and in class so that by
the time the episode came out, people at school would say
"Oh, well, she was just acting -- see, she really slumps like
everybody else so she's actually cool." She made it a habit.
Now, ten years later, she's noticing back problems and trying to get
over that habit and fix her bad posture, and it's not easy! And of
course, at the time nobody noticed and it didn't make a bit of
difference to her school popularity.
On word problems, her book offers a table helping people in mapping
real-world word problems to the right equation (for example, if it
says "a third of", that means 1/3 *).
She also stresses using problems
about subjects students care about. Co-host Justin
comments that word problems in school math books always tended to
be obsessed with trains leaving station A and arriving at station B,
which doesn't relate to most kids' lives very much. Why not,
Danica suggests, design word
problems about buying magazines or sharing chocolate bars?
Anyway, it's a great interview, and I hope her book sells well
and changes the world. I have a presentation coming up myself to
a middle school girls' group in a few days (on astronomy) and I'm
going to pick up a copy to make sure the girls know about it.
McKellar's website is
mathdoesntsuck.com
and you can listen to the whole interview on the
TWIS podcast.
If you like science podcasts, you'll want to
check out TWIS anyway. They cover cool stuff and they do it well,
with the nice bonus that it's hosted by a very sharp woman,
Dr. Kirsten Sanford (plus goofy guy sidekick Justin Jackson).
This particular episode starts with a fun and detailed discussion on
listener responses to the "falling through a tube drilled through the
center of the Earth" problem before they get to the interview.
Check it out!
The SF Chronicle's solicited reader comments on San Francisco's new
parking meter proposal.
My favorite response:
What about the handicapped cars that get to park for free? That needs
to stop.
I'm visualizing the poor cars limping in on their flat tires and
wobbly CV joints, motors puffing blue smoke ... and then they
finally find a place to rest, and ... dang, no hands to put coins
in the meter!
On a recent Mojave desert trip, we tried to follow a minor dirt road
that wasn't mapped correctly on any of the maps we had, and eventually
had to retrace our steps. Back at the hotel, I fired up my trusty
PyTopo on the East
Mojave map set and tried to trace the road. But I found that as I
scrolled along the road, things got slower and slower until it
just wasn't usable any more.
PyTopo was taking up all of my poor laptop's memory. Why?
Python is garbage collected -- you're not supposed to have
to manage memory explicitly, like freeing pixbufs.
I poked around in all the sample code and man pages I had available
but couldn't find any pygtk examples that seemed to be doing any
explicit freeing.
When we got back to civilization (read: internet access) I did
some searching and found the key. It's even in the
PyGTK
Image FAQ, and there's also some discussion in a
mailing
list thread from 2003.
Turns out that although Python is supposed to handle its own garbage
collection, the Python interpreter doesn't grok the size of a pixbuf
object; in particular, it doesn't see the image bits as part of the
object's size. So dereferencing lots of pixbuf objects doesn't trigger
any "enough memory has been freed that it's time to run the garbage
collector" actions.
The solution is easy enough: call gc.collect() explicitly
after drawing a map (or any other time a bunch of pixbufs have been
dereferenced).
So there's a new version of PyTopo, 0.6
that should run a lot better on small memory machines, plus
a new collection format (yet another format from
the packaged Topo! map sets) courtesy of Tom Trebisky.
Oh ... in case you're wondering, the ancient USGS maps from
Topo! didn't show the road correctly either.
The local Safeway has an interesting exercise in applied consumer
mathematics in the sugar aisle.
Sugar cubes come in two sizes. You can get a one-pound box for $1.68,
or a two-pound box for $3.86. Of course, the larger size is always
a better bargain, right?
Let's check that. 1.68 times two is ... carry the one ... $3.36.
Compare to $3.86 for the two-pound box ... um, why exactly should
anyone buy the two-pound box instead of two one-pound boxes?
But you don't even have to do the math yourself.
Safeway has already calculated the price per ounce and helpfully
provides shelf tags giving you the numbers:
You might think this is a one-time oddity, but it's actually
been the case for at least a year. In fact, several months ago
the price premium for the 2 lb box over the 1 lb actually
increased. I guess plenty of consumers are jumping
at the chance to buy sugar cubes in the large economy size.
It's nearly autumn, and that's the time of year when a girl's heart
turns to ...
BIG FAT HAIRY SPIDERS!
That's right, the tarantulas are on the move.
Mostly, tarantulas are hard to see. They stay in their underground
burrows for most of their lives; if they do come out of the burrow,
it's likely to be at night.
But for a few weeks each fall, male tarantulas become more
adventurous, when they emerge from their burrows and wander in search
of females. The females stay snug underground,
but the males can often be spotted on roads and trails, if you
know where and when to look.
Ah, but where and when?
I've seen tarantulas numerous times at Alum Rock Park (in San Jose)
and at Arastradero (in Palo Alto) ... but not in the last four years.
In recent years, Dave and I have gone out every October looking for
spiders, and have struck out locally. (Fortunately we've had better
luck on trips, so not all of these years were completely
tarantuless -- we've found them in places like Arizona's
Valley of the Gods
and Utah's Kolob Canyon.)
This year, we got started early, in September.
We had no luck at Alum Rock last weekend,
so this evening we took a late-afternoon hike a little higher
up in the east bay hills, at Grant Ranch.
On the trail by Grant Lake, we got rattled at by a fairly large western
rattlesnake, saw an underground beehive as well as lots of small
wasps, watched a flock of wild turkeys down by the parking lot,
and found a lovely feather from the blue heron at the lake.
But ... no spiders.
So we got back in the car and continued up Mt Hamilton Rd toward
the upper parking lot (Twin Gates). About two-thirds of the way there,
Dave spotted our quarry: a tarantula crossing the road. We found a
pullout and ran back with cameras.
After the photo session, we continued up the road to Twin
Gates for another mini-hike. Again, we saw no tarantulas on the
trail -- just hawks and kites, an oak tree covered with acorn
woodpecker holes (with the woodpeckers themselves darting among the
branches), and another oak tree being killed by mistletoe.
We returned to the car and headed back down the road -- and bagged
the day's second spider, scurrying across one of the roadside
pullouts. A nice end to the day's spider hunt!
The new semester started last week. I'm taking a class
that's held in a new building:
When Dave first saw the building, he laughed. "No wonder they're
complaining that fewer students are taking science and math classes --
they're sending the wrong message! They ought to call it 'Science
Simple'. Then they'd get lots of students signing up."
It's always amazed me that Linux doesn't let you customize the system
beep. You can call xset b volume pitch duration to
make it beep higher or lower, or you can turn it off or switch
to "visual bell"; but there's nothing like the way most other OSes
let you customize it to any sound you want. (Some desktops let you
customize the desktop alerts, but that doesn't do anything about the
beeping you get from vim, or emacs, or bash, or a hundred other
programs that run in terminals.)
Today someone pointed me toward a
Gentoo
wiki page that led me to
Fancy Beeper
Daemon. This is a small kernel module that adds a device,
/dev/beep, which outputs a byte every time there's a beep.
You can write a very simple daemon (several samples in Python are
included with the module) which reads /dev/beep and plays the
sound of your choice.
I downloaded beep-2.6.15+.tar.gz, but it needed one tweak
to build it under 2.6.23-rc3: I needed to add
#include <linux/sched.h>
among the includes at the beginning of beep.c.
After that, it compiled and installed just fine.
Since it's a kernel module, it works in consoles as well as under X.
/dev/beep is created with owner and group root, and readable/
writable only by owner and group, so to test it I had to
chmod 666 /dev/beep to run the daemon. I fixed that by
making a file in /etc/udev/rules.d called 41-beep.rules,
containing:
KERNEL=="beep", GROUP="audio"
Finally, based on the nice samples that came with the module, I wrote
my own very simple Python daemon,
playbeepd,
that uses aplay.
Lots of fun! I don't know how much I'll use it, but it's good to have
the option of custom beep sounds.
I left the water on too long in the garden again. I keep doing
that: I'll set up something where I need to check back in five minutes or
fifteen minutes, then I get involved in what I'm doing and 45 minutes
later, the cornbread is burnt or the garden is flooded.
When I was growing up, my mom had a little mechanical egg timer.
You twist the dial to 5 minutes or whatever, and it goes
tick-tick-tick and then DING! I could probably
find one of those to buy (they're probably all digital now
and include clocks and USB plugs and bluetooth ports) but since the
problem is always that I'm getting distracted by something on the
computer, why not run an app there?
Of course, you can do this with shell commands. The simple solution
is:
(sleep 300; zenity --info --text="Turn off the water!") &
But the zenity dialogs are small -- what if I don't notice it? --
and besides, I have to multiply by 60 to turn a minute delay into
sleep seconds. I'm lazy -- I want the computer to do that for me!
Update: Ed Davies points out that "sleep 5m" also works.
A slightly more elaborate solution is at. Say something like:
at now + 15 minutes
and when it prompts for commands, type something like:
export DISPLAY=:0.0
zenity --info --text="Your cornbread is ready"
to pop up a window with a message.
But that's too much typing and has the same problem of the small
easily-ignored dialogs. I'd really rather have a great big red
window that I can't possibly miss.
Surely, I thought, someone has already written a nice egg-timer
application! I tried aptitude search timer and found several
apps such as gtimer, which is much more complicated than I wanted (you
can define named events and choose from a list of ... never mind, I
stopped reading there). I tried googling, but didn't have much luck
there either (lots of Windows and web apps, no Linux apps or
cross-platform scripts).
Clearly just writing the damn thing was going to be easier than
finding one.
(Why is it that every time I want to do something simple on a computer,
I have to write it? I feel so sorry for people who don't program.)
I wanted to do it in python, but what to use for the window that pops up?
I've used python-gtk in the past, but I've been meaning to check out
TkInter (the gui toolkit that's kinda-sorta part of Python) and
this seemed like a nice opportunity since the goal was so simple.
The resulting script:
eggtimer.
Call it like this:
eggtimer 5 Turn off the water
and in five minutes, it will pop up a huge red window the size of the
screen with your message in big letters. (Click it or hit a key to
dismiss it.)
First Impressions of TkInter
It was good to have an excuse to try TkInter and compare it with python-gtk.
TkInter has been recommended as something normally installed
with Python, so the user doesn't have to install anything extra.
This is apparently true on Windows (and maybe on Mac), but on
Ubuntu it goes the other way: I already had pygtk, because GIMP
uses it, but to use TkInter I had to install python-tk.
For developing I found TkInter irritating. Most
of the irritation concerned the poor documentation:
there are several tutorials demonstrating very basic uses, but
not much detailed documentation for answering questions like "What
class is the root Tk() window and what methods does it have?"
(The best I found -- which never showed up in google, but was
referenced from O'Reilly's Programming Python -- was
here.)
In contrast, python-gtk is
very well documented.
Things I couldn't do (or, at least, couldn't figure out how to do, and
googling found only postings from other people wanting to do the same thing):
Button didn't respond to any of the obvious keys, like Return or
Space, and in fact setting key handlers on the button didn't work --
I ended up setting a key handler on the root window.
I couldn't find a way to set the root window size and background
explicitly, so I had to set approximate window size by guessing at
the size of the internal padding of the button.
There's an alternate to the root Tk() window called
Toplevel, which is documented and does allow setting window
size. Unfortunately, it also pops up an empty dialog without being
told to (presumably a bug).
All of the tutorials I found for creating dialogs was wrong,
and I finally gave up on dialogs and just used a regular window.
I couldn't fork and return control to the shell, because TkInter
windows don't work when called from a child process (for reasons no
one seems to be able to explain), so you have to run it in the
background with & if you want your shell prompt back.
I expect I'll be sticking with pygtk for future projects.
It's just too hard figuring things out with no documentation.
But it was fun having an excuse to try something new.
On a seemingly harmless trip to Fry's,
my mother got a look at the 22-inch widescreen LCD monitors
and decided she had to have one. (Can't blame her ... I've been
feeling the urge myself lately.)
We got the lovely new monitor home, plugged it in, configured X
and discovered that the screen showed severe vertical banding.
It was beautiful at low resolutions, but whenever we went to
the monitor's maximum resolution of 1680x1050, the bands appeared.
After lots of testing, we tentatively pinned the problem
down to the motherboard.
It turns out ancient machines with 1x AGP motherboards
can't drive that many pixels properly,
even if the video card is up to the job. Who knew?
Off we trooped to check out new computers.
We'd been hinting for quite some time that it might be about
time for a new machine, and Mom was ready to take the plunge
(especially if it meant not having to return that beautiful monitor).
We were hoping to find something with a relatively efficient Intel Core 2
processor and Intel integrated graphics: I've been told the Intel
graphics chip works well with Linux using open source drivers.
(Mom, being a person of good taste, prefers Linux, and none of us
wanted to wrestle with the proprietary nvidia drivers).
We found a likely machine at PC Club. They were even willing to
knock $60 off the price since she didn't want Windows.
But that raised a new problem. During our fiddling with her old
machine, we'd tried burning a Xubuntu CD, to see if the banding
problem was due to the old XFree86 she was running. Installing it hadn't
worked: her CD burner claimed it burned correctly, but the resulting
CD had errors and didn't pass verification. So we needed a CD burned.
We asked PC Club when buying the computer whether we might burn the
ISO to CD, but apparently that counts as a "data transfer" and their
minimum data transfer charge is $80. A bit much.
No problem -- a friend was coming over for dinner that night,
and he was kind enough to bring his Mac laptop ...
and after a half hour of fiddling, we determined that his burner
didn't work either (it gave a checksum error before starting the
burn). He'd never tried burning a CD on that laptop.
What about Kinko's? They have lots of data services, right?
Maybe they can burn an ISO. So we stopped at Kinko's after dinner.
They, of course, had never heard of an ISO image and had no idea how
to burn one on their Windows box.
Fearing getting a disk with a filesystem containing one file named
"xubuntu-7.04-alternate-i386.iso", we asked if they had a mac,
since we knew how to burn an ISO there.
They did, though they said sometimes the CD burner was flaky.
We decided to take the risk.
Burning an ISO on a mac isn't straightforward -- you have to do
things in exactly the right order.
It took some fast talking to persuade them of the steps ("No, it
really won't work if you insert the blank CD first. Yes, we're quite
sure") and we had to wait a long time for Kinko's antivirus software
to decide that Xubuntu wasn't malware, but 45 minutes and $10 later,
we had a disc.
And it worked! We first set up the machine in the living room, away
from the network, so we had to kill aptitude update
when the install hung installing "xubuntu-desktop" at 85%
(thank goodness for alternate consoles on ctl-alt-F2) but otherwise
the install went just fine. We rebooted, and Xubuntu came up ...
at 1280x1024, totally wrong. Fiddling with the resolution in xorg.conf
didn't help; trying to autodetect the monitor with
dpkg-reconfigure xorg crashed the machine and we had to
power cycle.
Back to the web ... turns out that Ubuntu "Feisty" ships with a bad
Intel driver. Lots of people have hit the problem, and we found a
few elaborate workarounds involving installing X drivers from various
places, but nothing simple. Well, we hadn't come
this far to take all the hardware back now.
First we moved the machine into the computer room, hooked up
networking and reinstalled xubuntu with a full network, just in
case. The resolution was still wrong.
Then, with Dave in the living room calling out steps off a web page
he'd found, we began the long workaround process.
"First," Dave suggested, reading, "check the version of
xserver-xorg-video-intel.
Let's make sure we're starting with the same version this guy is."
dpkg -l xserver-xorg-video-intel ... "Uh, it isn't
installed," I reported. I tried installing it. "It wants to remove
xserver-xorg-video-i810." Hmm! We decided we'd better do it,
since the rest of the instructions depended on having the
intel, not i810, driver.
And that was all it needed! The intel driver autodetected the monitor
and worked fine at 1680x1050.
So forget the elaborate instructions for trying X drivers from various
sources.
The problem was that xubuntu installed the wrong driver:
the i810 driver instead of the more generic intel driver.
(Apparently that bug is fixed for the next Ubuntu release.)
With that fix, it was only a few more minutes before Mom was
happily using her new system, widescreen monitor and all.
Dave and I are helping my mom shop for a new computer to drive a
22-inch widescreen monitor, 1680x1050 (long story, more on that later).
This is how we find ourselves in Circuit City staring at a
candidate PC on the lower shelf running a 19-inch widescreen at 1440x900.
Unfortunately that's not the resolution we were hoping to check.
There's an unplugged 22-inch LCD on the shelf right above it,
just like the one we're trying to get working.
A salesguy comes by and ask if we have any questions, so I ask him,
"Is there any way we can plug that monitor into this computer to see
if it works?" and explain our mission.
He's amenable, and plugs it in,
but Windows doesn't notice the new monitor. I try Display
Settings but it's still maxed out at 1440x900.
I ask the salesguy, "Can we try rebooting or something?
Maybe that'll make Windows see it."
He looks puzzled. "But it's already running a widescreen monitor."
I point to the Display Settings window. "But it's only running at
1440x900, and that's the most it'll let us use."
He says, "Oh, you wanted to run that 22-inch at full resolution?"
I'm forever having problems connecting to wireless networks,
especially with my Netgear Prism 54 card. The most common failure mode:
I insert the card and run /etc/init.d/networking restart
(udev is supposed to handle this, but that stopped working a month
or so ago). The card looks like it's connecting, ifconfig eth0
says it has the right IP address and it's marked up -- but try to
connect anywhere and it says "no route to host" or
"Destination host unreachable".
I've seen this both on networks which require a WEP key
and those that don't, and on nets where my older Prism2/Orinoco based
card will connect fine.
Apparently, the root of the problem
is that the Prism54 is more sensitive than the Prism2: it can see
more nearby networks. The Prism2 (with the orinoco_cs driver)
only sees the strongest network, and gloms onto it.
But the Prism54 chooses an access point according to arcane wisdom
only known to the driver developers.
So even if you're sitting right next to your access point and the
next one is half a block away and almost out of range, you need to
specify which one you want. How do you do that? Use the ESSID.
Every wireless network has a short identifier called the ESSID
to distinguish it from other nearby networks.
You can list all the access points the card sees with:
iwlist eth0 scan
(I'll be assuming eth0 as the ethernet device throughout this
article. Depending on your distro and hardware, you may need to
substitute ath0 or eth1 or whatever your wireless card
calls itself. Some cards don't support scanning,
but details like that seem to be improving in recent kernels.)
You'll probably see a lot of ESSIDs like "linksys" or
"default" or "OEM" -- the default values on typical low-cost consumer
access points. Of course, you can set your own access point's ESSID
to anything you want.
So what if you think your wireless card should be working, but it can't
connect anywhere? Check the ESSID first. Start with iwconfig:
iwconfig eth0
iwconfig lists the access point associated with the card right now.
If it's not the one you expect, there are two ways to change that.
First, change it temporarily to make sure you're choosing the right ESSID:
iwconfig eth0 essid MyESSID
If your accesspoint requires a key, add key nnnnnnnnnn
to the end of that line. Then see if your network is working.
If that works, you can make it permanent. On Debian-derived distros,
just add lines to the entry in /etc/network/interfaces:
wireless-essid MyESSID
wireless-key nnnnnnnnnn
Some older howtos may suggest an interfaces line that looks like this:
up iwconfig eth0 essid MyESSID
Don't get sucked in. This "up" syntax used to work (along with pre-up
and post-up), but although man interfaces still mentions it,
it doesn't work reliably in modern releases.
Use wireless-essid instead.
Of course, you can also use a gooey tool like
gnome-network-manager to set the essid and key. Not being a
gnome user, some time ago I hacked up the beginnings of a standalone
Python GTK tool to configure networks. During this week's wi-fi
fiddlings, I dug it out and blew some of the dust off:
wifi-picker.
You can choose from a list of known networks (including both essid and
key) set up in your own configuration file, or from a list of essids
currently visible to the card, and (assuming you run it as root)
it can then set the essid and key to whatever you choose.
For networks I use often, I prefer to set up a long-term
network
scheme, but it's fun to have something I can run once to
show me the visible networks then let me set essid and key.
The best thing at Linuxworld was the Powertop BOF,
despite the fact that it ended up stuck in a room with no projector.
The presenter, Arjan van de Ven, coped well with the setback and
managed just fine.
The main goal of Powertop is to find applications that are polling or
otherwise waking the CPU unnecessarily,
draining power when they don't need to.
Most of the BOF focused on "stupid stuff": programs that wake up
too often for no reason. Some examples he gave (many of these will
be fixed in upcoming versions of the software):
gnome-screensaver checked every 2 sec to see if the mouse moved
(rather than using the X notification for mouse move);
gnome volume checked 10 times a second whether the volume has changed;
gnome-clock woke up once a second to see if the minute had rolled
over, rather than checking once a minute;
firefox in an ssl layer polled 10 times a second in case there was a
notification;
the gnome file monitor woke up 40 times a second to check a queue
even if there was nothing in the queue;
evolution woke up 10 times a second;
the fedora desktop checked 10 times a second for a smartcard;
gksu used a 10000x/sec loop (he figures someone mistook
milliseconds/microseconds: this alone used up 45 min on one battery test run)
Adobe's closed-source flash browser plugin woke up 2.5 times a
second, and acroread had similar problems (this has been reported to
Adobe but it's not clear if a fix is coming any time soon).
And that's all just the desktop stuff, without getting into other
polling culprits like hal and the kernel's USB system. The kernel
itself is often a significant culprit: until recently, kernels woke
up once a millisecond whether they needed to or not. With the recent
"tickless" option that appeared in the most recent kernel, 2.6.22,
the CPU won't wake up unless it needs to.
A KDE user asked if the KDE desktop was similarly bad. The answer
was yes, with a caveat: Arjan said he gave a presentation a while back
to a group of KDE developers, and halfway through, one of the
developers interrupted him when he pointed out a problem
to say "That's not true any more -- I just checked in a fix while
you were talking." It's nice to hear that at least some developers
care about this stuff! Arjan said most developers responded
very well to patches he'd contributed to fix the polling issues.
(Of course, those of us who use lightweight window managers like
openbox or fvwm have already cut out most of these gnome and kde
power-suckers. The browser issues were the only ones that applied
to me, and I certainly do notice firefox' polling: when the laptop
gets slow, firefox is almost always the culprit, and killing it
usually brings performance back.)
As for hardware, he mentioned that
some linux LCD drivers don't really dim the backlight when you
reduce brightness -- they just make all the pixels darker.
(I've been making a point of dimming my screen when running off batteries;
time to use that Kill-A-Watt and find out if it actually matters!)
Wireless cards like the ipw100 use
a lot of power even when not transmitting -- sometimes even more than
when they're transmitting -- so turning them off can be a big help.
Using a USB mouse can cut as much as half an hour off a battery.
The 2.6.23 kernel has lots of new USB power saving code, which should help.
Many devices have activity every millisecond,
so there's lots of room to improve.
Another issue is that even if you get rid of the 10x/sec misbehavers,
some applications really do need to wake up every second or so. That's
not so bad by itself, but if you have lots of daemons all waking up at
different times, you end up with a CPU that never gets to sleep.
The solution is to synchronize them by rounding the wakeup times to
the nearest second, so that they all wake up at
about the same time, and the CPU can deal with them
all then go back to sleep. But there's a trick: each machine has to
round to a different value. You don't want every networking
application on every machine across the internet all waking up at once
-- that's a good way to flood your network servers. Arjan's phrase:
"You don't want to round the entire internet" [to the same value].
The solution is a new routine in glib: timeout_add_seconds.
It takes a hash of the hostname (and maybe other values) and uses that
to decide where to round timeouts for the current machine.
If you write programs that wake up on a regular basis, check it out.
In the kernel, round_jiffies does something similar.
After all the theory, we were treated to a demo of powertop in action.
Not surprisingly, it looks a bit like top. High on the screen
is summary information telling you how much time your CPU is spending
in the various sleep states. Getting into the deeper sleep states is
generally best, but it's not quite that simple: if you're only getting
there for short periods, it takes longer and uses more power to get
back to a running state than it would from higher sleep states.
Below that is the list of culprits: who is waking your CPU up most
often? This updates every few seconds, much like the top
program. Some of it's clear (names of programs or library routines);
other lines are more obscure if you're not a kernel hacker, but
I'm sure they can all be tracked down.
At the bottom of the screen is a geat feature: a short hint telling
you how you could eliminate the current top offender (e.g. kill the
process that's polling). Not only that, but in many cases powertop
will do it for you at the touch of a key. Very nice! You can try
disabling things and see right away whether it helped.
Arjan stepped through killing several processes and showing the
power saving benefits of each one. (I couldn't help but notice, when
he was done, that the remaining top offender, right above nautilus,
was gnome-power-manager. Oh, the irony!)
It's all very nifty and I'm looking forward to trying it myself.
Unfortunately, I can't do that on the
laptop where I really care about battery life. Powertop requires a
kernel API that went in with the "tickless" option, meaning it's
in 2.6.22 (and I believe it's available as a patch for 2.6.21).
My laptop is stuck back on 2.6.18 because of an IRQ handling bug (bug 7264).
Powertop also requires ACPI, which I have to disable
because of an infinite loop in kacpid (bug 8274,
Ubuntu bug
75174). It's frustrating to have great performance tools like
powertop available, yet not be able to use them because of kernel
regressions. But at least I can experiment with it on my desktop
machine.
There wasn't much of interest on the exhibit floor. Lots of
small companies doing virtualization or sysadmin tools.
The usual assortment of publishers. A few big companies,
but fewer than in past years. Not much swag. Dave commented
that there was a much higher "bunny quotient" this year than
last (lots of perky booth bunnies, very few knowledgeable people
working the floor). The ratio of Linux to Windows in the big-company
booths was much lower than last year, especially at AMD and HP,
who both had far more Windows machines visible than Linux ones.
The most interesting new hardware was the Palm Foleo. It looks
like a very thin 10-inch screen laptop, much like my own Vaio only
much thinner and lighter, with a full QWERTY keyboard with a good
feel to it. The booth staff weren't very technical, but apparently
it sports a 300MHz Intel processor, built-in wi-fi and bluetooth,
a resolution a hair under 1024x768 (I didn't write down the
exact numbers and their literature doesn't say), a claimed battery
life of 5 hours, and runs a Linux from Wind River.
The booth rep I talked to said
it would run regular Linux apps once they were recompiled for
the processor, but he didn't seem very technical and I doubt it
runs X, so I'm not sure I believe that. For a claimed price of
around $400 it looks potentially quite interesting.
Their glossy handout says it has VGA out and can display PowerPoint
presentations, which was interesting since the only powerpoint
reader I know of on Linux is OpenOffice and I don't see that
running on 300MHz (considering how slow it is on my P3 700).
Apparently they're using Documents To Go from DataVis, a PalmOS app.
Aside from that there wasn't much of interest going on.
They split up the "Dot Org Pavilion" this year so not all the
community groups were in the same place, which was a bummer --
usually that's where all the interesting booths are (local LUGs,
FSF, EFF, Debian, Ubuntu and groups like that: no Mozilla booth
this time around). But this year
the dotorgs were too spread out to offer a good hangout spot.
It didn't look like there was much of interest at the conference
either: this year they gave us Exhibit Hall pass attendees a free
ticket to attend one of the paid talks, and I couldn't find one
on the day we attended that looked interesting enough to bother.
However, that changed at the end of the day with the BOF sessions.
The Intel Powertop BOF was an easy choice -- I've been curious about
Powertop ever since it was announced, and was eager to hear more about
it from one of the developers. The BOF didn't disappoint, though the
room did: they didn't even provide a projector (!), so we all had
to cluster around the presenter's laptop when he wanted to show
something. Too bad! but it didn't keep the BOF from being full of
interesting information.
I'll split that off into a separate article.
All the news media carried stories on how our (US) legislators
voted in a bill on Friday night that greatly eased the rules on
wiretapping. The House followed through and passed the bill on
Saturday.
The new updates to FISA, the Foreign Intelligence Surveillance Act,
will allow the NSA or the attorney general to authorize
monitoring of telephones or email, without a warrant, if the
comunications involve people
"reasonably believed to be outside the United States".
The story reported in most of the papers is that Democrats were against
the bill and wanted a version which required warrants in more cases.
But the President threatened
to hold Congress in session into its scheduled summer recess if it did
not approve the changes he wanted -- and that was enough,
apparently, for the Senate to vote for warrantless surveillance of
Americans. (I confess I don't quite understand why the president can
hold Congress in session indefinitely until he gets the vote he wants.
Can't they just vote No?)
What I couldn't find in any of the stories was a breakdown of the
votes. What about our presidential candidates? Did they support
warrantless wiretapping -- or, perhaps worse, just not care about
the ramifications of a bill if further consideration of it might cut
into their vacation time?
The House is harder. They
don't seem to have a nice "recent votes" page like the Senate does,
or any obvious way to find bills (I had little luck with their site
search), though a pressec.com
story gave a link to the bill on Thomas.loc.gov,
which links to an official House.gov vote count.
In the absence of pressec.com's help, the easiest way to find House
voting records is to use the
Washington Post
Votes Database.
How did they vote?
I was happy to see that all the major Democratic candidates in
Congress voted against the smarmily named "Protect America Act",
including Hillary Clinton, Barack Obama, Joe Biden, and Christopher Dodd,
and (in the House) Dennis Kucinich.
John Kerry (who is not an official candidate) didn't vote.
On the Republican side, candidate Sam Brownback voted for the bill,
while candidates John McCain, Tom Tancredo and Ron Paul didn't vote.
Of course, I was also interested in my local legislators.
California Senator Dianne Feinstein voted for passage
(why do people keep voting her back in?)
while our other senator, Barbara Boxer didn't vote.
In the House, my representative, the always sensible Zoe Lofgren,
voted against the bill. In fact, she spoke
out against it, saying "This bill would grant the attorney
general the ability to wiretap anybody, any place, any time without
court review, without any checks and balances.
I think this unwarranted, unprecedented measure would simply
eviscerate the 4th Amendment." Hurray, Zoe!
House Speaker Nancy Pelosi also voted against.
It's a small thing, but xchat's blinking text cursor has irritated
me for a while. It's not so much the blink itself that bothers me,
but that it makes the mouse pointer flicker. (I have no idea why
blinking the cursor should make the X mouse pointer flicker,
but it was pretty clear that they were in sync.)
I've also seen fingers pointed at
cursor blink as a laptop battery eater (one more reason the CPU has
to wake up every second or so when it might otherwise have been
idling) though I've seen no numbers on how significant that might
be (probably not very, on most laptops).
Anyway, there are reasons enough to look into turning off the blink.
Xchat is a gtk application, of course. There are lots and
lots of pages on the web telling developers about gtk's
gtk-cursor-blink property (and related properties like
gtk-cursor-blink-timeout) and what they do in at a library
level, so it's clearly possible. But I found nothing about where a
user should set these properties to make gtk find them.
Here's the answer. Add to $HOME/.gtkrc-2.0
(or any other file loaded by $HOME/.gtkrc-2.0):
gtk-cursor-blink = 0
I had to restart X (maybe shutting down all gtk apps would have
been enough) before I saw any effect.
While I was searching, I did find a nice page on
How to disable
blinking cursors in lots of different apps. Its gtk section
didn't seem to do anything here (maybe it only works if a gnome
desktop is running), but it's a good page nontheless,
full of useful advice for turning off cursor blink in other programs.
I don't usually spend a lot of time reading the sides of Diet Coke
cartons, but maybe I should. There's some good scholarly writing
there. For instance, did you know that, according to the Diet Coke
carton,
"It's true. Research shows that all beverages contribute to proper hydration.
That means [ ... ] Diet Coke helps you stay hydrated all day long."
I'm visualizing a big laboratory full of spectacled scientists in
white lab coats, cages full of lab rats with hanging water bottles
filled with hundreds of different beverages. The sign outside
the building says "School of Hydration Science".
I wonder which journals publish the peer-reviewed hydration research papers?
Non-diet Coke cartons have almost the same note,
except they leave out the "Research shows" part. I wonder if that means
the lab rats didn't stay properly hydrated with regular Coke,
so they had to toss those data points out of the final paper?
We were heading past the scum pond at Walden West for a quick
afternoon hike when I heard Dave, just ahead of me, make a very loud
and very rude noise.
Or maybe not. He immediately turned around and asked, "Was that you?"
I insisted truthfully that it wasn't.
Weird! We walked on, and behind us we heard more odd noises --
sometimes like machinery, and sometimes like a cow bellowing.
We figured it was part of the summer school at Walden West --
maybe they bring in barnyard animals to show the kids.
But the cow bellowing was still going on when we got back to the
car, and we could tell now it wasn't coming from the school.
It was coming from the pond. A thought occurred to me -- "What
do bullfrogs sound like? Like, maybe, a bull?" I had to go see.
Sure enough, the green, scummy pond was covered with big frogs!
I counted about 9 visible at any one time.
Mostly they were just floating in the scum, but every now and then
one would bellow, or dive and swim somewhere else.
Mostly they ignored us ... except the ones near the edge of the pond.
If we tried to walk up near them and look down on them, they
disappeared underwater immediately. Maybe we looked like a heron
or egret.
I know I'm supposed to hate bullfrogs. They're an invasive species
with a voracious appetite for local species. My bio teacher told us
to kill them on sight if possible (not that we could have done so here
even if we'd wanted to). But I found it fun and unusual to see any frog
at all here ... let alone a frog chorus right in front of us in
broad daylight.
I've been a happy csh/tcsh user for decades. But every now and then I
bow to pressure and try to join the normal bash-using Linux world.
But I always come up against one problem right away: word erase
(Control-W). For those who don't use ^W, suppose I type something like:
% ls /backups/images/trips/arizona/2007
Then I suddenly realize I want utah in 2007, not arizona.
In csh, I can hit ^W twice and it erases the last two words, and I'm
ready to type u<tab>.
In bash, ^W erases the whole path leaving
only "ls", so it's no help here.
It may seem like a small thing, but I use word erase hundreds of
times a day and it's hard to give it up. Google was no help, except
to tell me I wasn't the only one asking.
Then the other day
I was chatting about this issue with a friend who uses zsh for that
reason (zsh is much more flexible at defining key bindings)
and someone asked, "Is that like Meta-Delete?"
It turned out that Alt-Backspace
(like many Linux applications, bash calls the Alt key "Meta",
and Linux often confuses Delete and Backspace)
did exactly what I wanted. Very promising!
But Alt-Backspace is not easy to type, since it's not reachable from
the "home" typing position.
What I needed, now that I knew bash and readline had the function,
was a way to bind it to ^W.
Bash's binding syntax is documented, though the functions available
don't seem to be. But bind -p | grep word gave me
some useful information. It seems that \C-w was bound to
"unix-word-rubout" (that was the one I didn't want) whereas "\e\C-?"
was bound to "backward-kill-word".
("\e\C-?" is an obscure way of saying Meta-DEL: \e is escape, and
apparently bash, like emacs, treats ESC followed by a key as the same
as pressing Alt and the key simultaneously. And Control-question-mark
is the Delete character in ASCII.)
So my task was to bind \C-w to backward-kill-word.
It looked like this ought to work:
bind '\C-w:backward-kill-word'
... Except it didn't.
bind -p | grep w
showed that C-W was still bound to "unix-word-rubout".
It turned out that it was the terminal (stty) settings causing
the problem: when the terminal's werase (word erase)
character is set, readline hardwires that character to do
unix-word-rubout and ignores any attempts to change it.
I found the answer in a
bash
bug report. The stty business was introduced in readline 5.0,
but due to complaints, 5.1 was slated to add a way to override
the stty settings. And happily, I had 5.2! So what was this new
way override method? The posting gave no hint, but eventually I found it.
Put in your .inputrc:
set bind-tty-special-chars Off
And finally my word erase worked properly and I could use bash!
I continue to be puzzled by the mysterious
chlorine small that
sometimes wafts through the redwood forests during the warm
days of summer.
It's been fairly noticable for about a month now, though it's
patchy and doesn't occur everywhere.
Today's hike was on a trail called "The Lonely Trail", up above
Woodside. It was just as well that it was lonely: no one could see
Dave and me (mostly me) stopping to sniff bushes and trees and rotting
logs and dirt. But alas, no definite culprit emerged.
It did seem stronger when we were next to tanoak trees, though that
is virtually everywhere in these forests.
Tanoak is short for Tanbark-Oak, or Lithocarpus densiflorus.
It's not a true oak (genus Quercus) and is more closely related
to chestnuts. But it's like oaks in many ways -- the tough, shiny
leaves look a bit like larger versions of our local coast live oak
(though the distinctive veins make it easy to tell the two apart).
The acorns, too, are very similar to those of live oaks.
The smell definitely wasn't coming from the tanoak leaves, but it did
seem stronger near the trunks of some of the tanoaks. I'd always
assumed "tan" referred to color (since there are white oaks, black
oaks, blue oaks and red oaks, none of which are really those
colors). But what if it refers to a tree whose bark is particularly
high in tannic acid? What does tannic acid smell like, anyway?
This would still leave some mysteries. Tanoaks are all over bay area
parks, not just in redwood forests. What is it about the deep, shady
redwood forests which bring out this smell, where it's seldom obvious
in the tanoaks of the valleys or rolling hills? Some interaction
between tanoaks and redwoods, or ferns? Something that only happens
in the shade?
I never found a tree that gave me a clear answer -- I merely picked
up subtle hints of chlorine odor from the trunks of a few trees.
Returning home to the digital world, I learned that
the tanoak tree is indeed very high in tannins, and was extensively
harvested for tanning hides. The local native Americans also used
the acorns for flour, after leaching them to remove the bitter acid.
I found no references to odor from tanoak bark or wood,
but a few pages mentioned that the flowers, which hang in catkins,
have a foul odor. No one goes into specifics on this odor.
I didn't see many flower catkins on today's hike,
but they're listed as appearing in June through October.
Looks like I have a research project lined up for the next outing.
I got email from a recruiter yesterday
alerting me to opportunities for "Engineers who are interested to
work in a fast paste environment with talented and passionate people!"
The email came from a reputable place and was well targeted,
not random spam like a lot of recruiter email.
I don't know, though ... It's good that they're talented and passionate,
but I've seen (and debugged) code that resulted from fast pastes,
and the result is often not pretty.
I think I'd prefer to work in a place where they designed the code
from scratch rather than just pasting it quickly.
I like buying from Amazon, but it's gotten a lot more difficult since
they changed their web page design to assume super-wide browser
windows. On the browser sizes I tend to use, even if I scroll right
I can't read the reviews of books, because the content itself is wider
than my browser window. Really, what's up with the current craze of
insisting that everyone upgrade their screen sizes then run browser
windows maximized?
(I'd give a lot for a browser that had the concept of "just show me
the page in the space I have". Opera has made some progress on this
and if they got it really working it might even entice me away from
Firefox, despite my preference for open source and my investment in
Mozilla technology ... but so far it isn't better enough to justify a
switch.)
I keep meaning to try the
greasemonkey extension,
but still haven't gotten around to it.
Today, I had a little time, so I googled to see if
anyone had already written a greasemonkey script to make Amazon readable.
I couldn't find one, but I did find a
page
from last October trying to fix a similar problem on another
website, which mentioned difficulties in keeping scripts working
under greasemonkey, and offered a Javascript bookmarklet with
similar functionality.
Now we're talking! A bookmarklet sounds a lot simpler and more secure
than learning how to program Greasemonkey. So I grabbed the
bookmarklet, a copy of an Amazon page, and my trusty DOM Inspector
window and set about figuring out how to make Amazon fit in my window.
It didn't take long to realize that what I needed was CSS, not
Javascript. Which is potentially a lot easier: "all" I needed to do
was find the right CSS rules to put in userContent.css. "All" is in
quotes because getting CSS to do anything is seldom a trivial task.
But after way too much fiddling, I did finally come up with a rule
to get Amazon's Editorial Reviews to fit. Put this in
chrome/userContent.css inside your Firefox profile directory
(if you don't know where your profile directory is, search your disk
for a file called prefs.js):
but nothing worked, and some of it (like the latter of those two
lines) actually interfered with the div.content rule for reasons
I still don't understand. (If any of you CSS gurus want to enlighten
me, or suggest a better or more complete solution, or solutions that
work with other web pages, I'm all ears!)
I'll try for a more complete solution some other time, but for now,
I'm spending my July 4th celebrating my independance from Amazon's
idea of the one true browser width.
Today's topics are three: the excellent comic called xkcd,
the use of google to search a site but exclude parts of that site,
and, most important, the useful Mozilla technique called Bookmarklets.
I found myself wanting to show someone a particular xkcd comic
(the one about dreams).
Xkcd, for anyone who hasn't been introduced, is a wonderfully
geeky, smart, and thoughtful comic strip drawn by Randall
Munroe.
How to search for a comic strip? Xkcd has an archive page but that
seems to have a fairly small subset of all the comics. But fortunately
the comics also have titles and alt tags, which google can index.
But googling for dreams site:xkcd.org gets me lots of
hits on xkcd's forum and blag pages (which I hadn't even known
existed) rather than just finding the comic I wanted. After some
fiddling, though, I managed to find a way to exclude all the fora
and blag pages: google for
xkcd dreams site:xkcd.com -site:forums.xkcd.com -site:fora.xkcd.com -site:blag.xkcd.com
Nifty!
In fact, it was so nifty that I decided I might want to use it again.
Fortunately, Mozilla browsers like Firefox have a great feature called
bookmarklets. Bookmarklets are like shell aliases in Linux:
they let you assign an alias to a bookmark, then substitute in your
own terms each time you use it.
That's probably not clear, so here's how it works in this specific
case:
I did the google search I listed above, which gave me this long
and seemingly scary URL:
http://www.google.com/search?hl=en&q=xkcd+dreams+site%3Axkcd.com+-site%3Aforums.xkcd.com+-site%3Afora.xkcd.com+-site%3Ablag.xkcd.com&btnG=Search
Bookmarks->Bookmark this page. Unfortunately Firefox
doesn't let you change any bookmark properties at the time you make
the bookmark, so:
Bookmarks->Organize Bookmarks, find the new bookmark
(down at the bottom of the list) and Edit->Properties...
Change the Name to something useful (I called it
Xkcd search)
then choose a simple word for the Keyword field. This is the "alias"
you'll use for the bookmark. I chose xkcd.
In the Location field, find the term you want to be
variable. In this case, that's "dreams", because I won't always be
searching for the comic about dreams, I might want to search for anything.
Change that term to %s.
(Note to non-programmers: %s is a term often used in programming
languages to mean "replace the %s with a string I'll provide
later.")
So now the Location looks like:
http://www.google.com/search?hl=en&q=xkcd+%s+site%3Axkcd.com+-site%3Aforums.xkcd.com+-site%3Afora.xkcd.com+-site%3Ablag.xkcd.com&btnG=Search
Save the bookmarklet (click OK) and, optionally, drag it
into a folder somewhere where it won't clutter up your bookmarks menu.
You aren't ever going to be choosing this from the menu.
Now I had a new bookmarklet. To test it, I went to the urlbar in
Firefox and typed:
xkcd "regular expressions"
Voila! The first hit was exactly the comic I wanted.
I upgraded my laptop's Ubuntu partition from Edgy to Feisty.
Debian Etch works well, but it's just too old and I can't build
software like GIMP that insists on depending on cutting-edge
libraries.
But Feisty is cutting edge in other ways, so
it's been a week of workarounds, in two areas: Firefox and the kernel.
I'll start with Firefox.
Firefox crashes playing flash
First, the way Ubuntu's Firefox crashes when running Flash.
I run flashblock, fortunately, so I've been able to browse the web
just fine as long as I don't click on a flashblock button.
But I like being able to view the occasional youtube video,
and flash 7 has worked fine for me on every distro except Ubuntu.
I first saw the problem on Edgy, and upgrading to Feisty didn't cure the
problem.
But it wasn't their Firefox build; my own "kitfox" firefox
build crashed as well. And it wasn't their flash installation; I've
never had any luck with either their adobe flash installer nor their
opensource libswfdec, so I'm running the same old flash 7 plug-in
that I've used all along for other distros.
To find out what was really happening, I ran Firefox from the
commandline, then went to a flash page. It turned out it was
triggering an X error:
The error was: 'BadMatch (invalid parameter attributes)'.
(Details: serial 104 error_code 8 request_code 145 minor_code 3)
That gave me something to search for. It turns out there's a longstanding
Ubuntu
bug, 14911 filed on this issue, with several workarounds.
Setting the environment variable XLIB_SKIP_ARGB_VISUALS to 1 fixed the
problem, but, reading farther in the bug, I saw that the real problem
was that Ubuntu's installer had, for some strange reason, configured
my X to use 16 bit color instead of 24. Apparently this is pretty
common, and due to some bug involving X's and Mozilla's or Flash's
handling of transparency, this causes flash to crash Mozilla.
So the solution is very simple. Edit /etc/X11/xorg.conf, look
for the DefaultDepth line, and if it's 16, that's your problem.
Change it to 24, restart X and see if flash works. It worked for me!
Eliminating Firefox's saved session pester dialog
While I was fiddling with Firefox, Dave started swearing. "Why does
Firefox always make me go through this dialog about restoring the last
session? Is there a way to turn that off?"
Sure enough, there's no exposed preference for this, so I poked around
about:config, searched for browser and found
browser.sessionstore.resume_from_crash. Doubleclick that
line to change it to false and you'll have no more pesky
dialog.
Alas, having upgraded to Feisty expressly so that I could build
cutting-edge programs like GIMP, I discovered that I couldn't build
anything at all. Anything that uses heavy CPU for more than a minute
or two triggers a kernel daemon, kacpid, to grab most of the CPU for
itself. Being part of the kernel (even though it has a process ID),
kacpi is unkillable, and prevents the machine from shutting down,
so once this happens the only solution is to pull the power plug.
This has actually been a longstanding Ubuntu problem
(bug 75174)
but it used to be that disabling acpid would stop kacpid from
running away, and with feisty, that no longer helps.
The bug is also
kernel.org
bug 8274.
The Ubuntu bug suggested that disabling cpufreq solved it for one
person. Apparently the only way to do that is to build a new kernel.
There followed a long session of attempted kernel building.
It was tricky because of course I couldn't build on the
target machine (inability to build being the problem I was trying to
solve), and even if I built on my desktop machine,
a large rsync of the modules directory would trigger a
runaway kacpi. In the end, building a standalone kernel with
no modules was the only option.
But turning off cpufreq didn't help, nor did any of the other obvious
acpi options. The only option which stops kacpid is to disable acpi
altogether, and use apm. I'm sorry to lose hibernate, and temperature
monitoring, but that appears to be my only option with modern kernels.
Sigh.
Kernel: Hangs for 2 minutes at boot time initializing sound card
While Dave and I were madly trying to find a set of config options to
build a 2.6.21 that would boot on a Vaio (he was helping out with his
SR33 laptop, starting from a different set of config options) we both
hit, at about the same time, an odd bug: partway through boot, the
kernel would initialize the USB memory stick reader:
sd 0:0:0:0: Attached scsi removable disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
and then it would hang, for a long time. Two minutes, as it turned
out. And the messages after that were pretty random: sometimes related
to the sound card, sometimes to the network, sometimes ... GConf?!
(What on earth is GConf doing in a kernel boot sequence?)
We tried disabling various options to try to pin down the culprit:
what was causing that two minute hang?
We eventually narrowed the blame to the sound card (which is a Yamaha,
using the ymfpci driver). And that was enough information for google
to find this
Linux Kernel Mailing List thread. Apparently the sound maintainer
decided, for some reason, to make the ymfpci driver depend on an
external firmware file ... and then didn't include the firmware file,
nor is it included in the alsa-firmware package he references in that
message. Lovely. I'm still a little puzzled about the timeout: the
post does not explain why, if a firmware file isn't found on the
disk, waiting for two minutes is likely to make one magically appear.
Apparently it will be fixed in 2.6.22, which isn't much help for
anyone who's trying to run a kernel on any of the 2.6.21.* series
in the meantime. (Isn't it a serious enough regression to fix in
2.6.21.*?) And he didn't suggest a workaround, except that
alsa-firmware package which doesn't actually contain the firmware
for that card.
Looks like it's left to the user to make things work.
So here's what to do: it turns out that if you take a 2.6.21 kernel,
and substitute the whole sound/pci/ymfpci directory from a 2.6.20
kernel source tree, it builds and boots just fine. And I'm off and
running with a standalone apm kernel with no acpi; sound works, and I
can finally build GIMP again.
So it's been quite a week of workarounds. You know, I used to argue
with all those annoying "Linux is not ready for the desktop"
people. But sometimes I feel like Linux usability is moving in the
wrong direction. I try to imagine explaining to my mac-using friends
why they should have to edit /etc/X11/xorg.conf because their distro
set up a configuration that makes Firefox crash, or why they need to
build a new kernel because the distributed ones all crash or hang
... I love Linux and don't regret using it, but I seem to need
workarounds like this more often now than I did a few years ago.
Sometimes it really does seem like the open source world is moving
backward, not forward.
Whew -- I think our resident squirrel Notch has finally had her long-overdue
litter. It wasn't immediately obvious, but she's been deflating over a
period of about a week. Since then she's gone off her mad burying
frenzy and gone back to eating the nuts we give her.
Last week, while she was still pregnant, she was kind enough to give
me a nice nut-burying exhibition right outside the office door, which
I got on video. She digs a hole, places the nut in and tries to pack
it down, decides it's not deep enough and pulls it out again, digs a
little deeper, jackhammers the nut into place with her nose, fills in
the hole then does her usual careful job of covering over the hole and
arranging leaves on top of it to hide the evidence.
Then she turns and digs up a nut that was buried two inches away and
eats it. Video
on youtube.
In other squirrel news, on an afternoon hike at Rancho San Antonio
yesterday I saw an Eastern Fox squirrel in the trees about halfway up the
first leg of the PG&E trail. Foxes are an invasive species (just
like Notch and her Eastern Grey friends who inhabit most of the
suburbs around here), so that's not good news for the native Western
Greys who have traditionally inhabited the park. I suppose it was just
a matter of time, since RSA is so close to suburbia, before the
non-native eastern squirrels invade and drive out the wimpy native
squirrels. It'll be interesting to see whether the western greys can
hold their own, or, if not, how long the invasion takes.
In non-squirrel news, we had a few very hot days last week (mid 90s)
and fled to the redwood forests to escape the heat one day, and
smelled that odd chlorine odor I've noticed before. The smell
was fairly faint this time. I asked my Bio teacher about it in class
last semester, but he didn't know what it might be, so it remains a
mystery for now. I'll be tracking whether it's there on all hot days,
or just some, this summer.
It was a bit over two years ago that I switched from
icewm to fvwm as my window manager. Fvwm proved to be very fast,
very configurable, and "good enough" most of the time. But lately,
I've found myself irritated with it, particularly with its tendency to
position windows off screen (which got a lot worse in 2.5.18).
It looked like it was time to try another window manager, so when
I learned that the Openbox
project is headed by a fellow
LinuxChixor, I had to try it.
Openbox impressed me right away. I'd tried it once before, a couple of years
ago, when I found it a little inconsistent and immature. It's grown up a
lot since then! It's still very fast and lightweight, but it has good
focus handling, excellent window positioning, a good configuration
window (obconf), and a wide variety of themes which are pretty but
still don't take up too much of my limited screen space.
But more important, what it has is a very active and friendly
community. I hit a couple of snags, mostly having to do with focus
handling while switching desktops (the problem that drove me off
icewm to fvwm), so I hopped onto the IRC channel and found myself
chatting with the active developers, who told me that most of my
problems had already been fixed in 3.4, and there were .deb files
on the website for both of the distros I'm currently using.
Indeed, that cured the problem; and when I later hit a more esoteric
focus bug, the developers (particularly Dana Jansens) were all over it
and fixed it that same day. Wow!
Since then I've been putting it through its paces. I have yet to see
a window positioned badly in normal usage, and it handles several
other problems I'd been seeing with fvwm, like focus handling when
popping up dialogs (all those secondary GIMP Save-as dialogs that
don't get focused when they appear). It's just as flexible as fvwm
was when it comes to keyboard and mouse configuration, maybe even
more so (plus it has lots of useful default bindings I might not
have thought of, like mousewheel bindings to change desktops or
"shade" a window).
I was going to stay out of theme configuration, because there were
several pretty good installed themes already. But then in response to
a half-joking question on my part of whether a particular theme came
in blue, someone on the IRC channel made me a custom theme file -- and
I couldn't resist tweaking it from there, and discovered that tweaking
openbox themes is just as easy as fiddling with its other defaults.
I don't use transparency (I find it distracting), but my husband is
addicted to transparent windows, so when I noticed on the web site
that openbox handles transparency I pointed him there. (He's been
using an old Afterstep, from back when it was still small and light,
but it's been a constant battle getting it to build under newer gccs.)
He reports that openbox handles transparency as well as afterstep did,
so he's switched too.
I haven't looked at the openbox code yet, but based on how fast the
developers add features and fix bugs, I bet it's clean, and I
hope I can contribute at some point.
Anyway, great focus handling, great window positioning, fast,
lightweight, super configurable, and best of all a friendly and
helpful developer and user community. What more could you ask for in a
window manager?
I'm an openbox convert. Thanks, Dana, Mikachu and all the rest.
Someone showed up on #gimp today with a color specified as an HTML
hex color specifier, and wanted to know how to find the nearest
color name.
Easy, right? There have got to be a bazillion pages that do that,
plus at least a couple of Linux apps.
But I googled for a while and couldn't find a single one. There
are lots of pages that list all the RGB colors, or convert decimal
red, green and blue into HTML #nnn hex codes, or offer aesthetic
advice about pleasing combinations of colors for themes (including
this lovely page on butterfly-inspired color themes,
courtesy of Rik) but nothing I could
find that gave color names. Apparently there used to be a Linux
app that did that, a piece of Gnome 1 called GColorSel,
but it's gone now.
I got to thinking (always dangerous!) ...
/etc/X11/rgb.txt has a list of color names
with their RGB color equivalents. It would be really easy to write
something that just read down the list finding the ones closest to
the specified color.
Uh-oh ... of course, once that thought occurred to me, I was doomed.
Programmer's disease. I had to write it. So I did, and here it is:
Find the
Nearest Matching Color Name. It checks against both rgb.txt
and the much smaller list of 17 CSS color names.
It's springtime in the backyard! I saw a couple of mockingbird
fledglings cheeping to be fed in the pyrocantha while we were having
dinner last night, though we never saw the mockingbird nest.
And we have a couple of California towhee fledgelings
who come by to eat sunflower seeds. Mama towhee first
brought them by one by one, broke the seeds up (apparently a
sunflower seed is a little too big for a towhee to swallow in one
piece) and fed them to the cheeping youngsters. But now they're coming
by on their own, and still having some trouble breaking
up the seeds, but they're making progress. Unfortunately one of the
chicks hops only on one foot, apparently having injured the other already.
It's springtime for our
local squirrels, too.
Ringtail, the fox squirrel, is still
around, and we have an occasional visit from a male fox squirrel as
well. Notch, our longtime resident grey squirrel diva,
is heavily pregnant. She looks like a little furry bowling pin
and we keep thinking she's going to have her litter at any moment,
but days pass and she continues to grow. We noticed her pregnancy some
time in mid-April (it was quite visible by then), and gestation is
supposed to be around 44 days, so either she's way overdue, or the
books are wrong about Eastern grey squirrel gestation. (Or she's just
fat and not pregnant at all, but I don't think so since her nipples
are very prominent too.)
She still moves remarkably gracefully and has no trouble with leaping
and climbing, unlike Nonotchka, who lumbered and waddled when she got
to this stage last summer.
But the real fun is a pair of baby squirrels who showed up a week
ago. We're calling the female Nova and her brother Chico (he has
slonchy ears that look like Chiquita's). We have no idea who their
mother is -- obviously not Notch, and we haven't seen any other
female greys in quite a while. The kids wear sleek summer coats,
while Notch still hasn't shed her shaggy winter fur despite the
warm weather.
This pair is much bolder and more athletic than Chiquita and Ringlet
were last year. They leap, they run along the fence, and they scamper
headfirst down tree trunks. They don't play together much at all,
the way last year's twins did, but sometimes they play by themselves.
This morning, we watched in amazement as Nova played by the guava
tree just outside the office door, alternating between pretend-burying
of walnut shells and wild gyrations, rolls and backflips.
What's up with portable radios that get great reception when your hand
is on them moving them around, but the minute you let go, the static
comes back?
I have a great business idea:
some entrepeneur should make an artificial hand you can drape over
your radio to get that effect to stay.
(Please no one mail me explaining capacitance. And in fact, it
turns out it works pretty well to lean a long metal bar against
the wall next to the radio. But I bet people would buy an
artificial hand antenna anyway!)
NPR this morning had a program
on speeding. One of the "experts" they brought in was
Richard Retting, senior transportation engineer with the IIHS
(that's the Insurance Institute for Highway Safety, a group funded
by auto insurance companies).
Early on they asked him why speeding was bad. He said there were
three reasons. The first two were straightforward: when you're going
faster, you (1) travel farther before you can react to something, and
(2) take longer to stop. No problem there, and I waited for the third
reason, presuming it was going to be kinetic energy.
Well, almost.
The third reason, he said, was energy. "Remember that equation
E = mc2 from high school?"
Wow! If I drive faster than the speed limit, I'm converting my mass
into energy?
For those who haven't studied physics recently, he was probably
confusing Einstein's equation relating energy, mass and the speed of
light with Newton's formula for kinetic energy,
KE = mv2/2. The host responded incredulously
"The speed of light?" but Retting didn't seem to notice, and pressed
on: "When you're going faster, your energy is disproportionate and
exponential."
Okay, you're talking on the radio and you have a brain-o.
I'm sure we've all said silly things when we knew better, like
reciting the wrong equation then not noticing the gaffe.
But he also
seems confused about what "exponential" means, perhaps because of that
"exponent" of 2 in the equation. An exponential
curve is when you
have something like 2X, not X2. Admittedly, the
dictionary of "exponential" includes vague definitions like
"Pertaining to exponents", and I suppose there is an exponent
of 2 involved. But really, folks: kinetic energy
increases as the square of speed.
A little later in the program, someone called in to mention studies
showing that higher speeds don't necessarily correlate with accidents,
and Redding chastised him for doing google searches for studies:
"That's not how we do science in this country." Hey, Mr. Retting --
it might pay to be a little more careful with your own science if
you're going to be dismiss callers with remarks like that.
A couple of friends periodically pester me to write about why
I stopped contributing to Mozilla after so many years with the
project. I've held back, feeling like it's airing dirty laundry
in public.
But a
discussion
on mozilla.dev.planning over the last week, started by Nelson
Bolyard, aired it for me: it was their culture of regressions.
I love Mozilla technology. I'm glad it exists, and I still use it for
my everyday browsing. But trying to contribute to Mozilla just got
too frustrating. I spent more time chasing down and trying to fix
other people's breakages than I did working on anything I
wanted to work on.
That might be okay, barely, when you're getting paid for it. But
when you're volunteering your own time, who wants to spend it fixing
code checked in by some other programmer who just can't be bothered to
clean up his own mess?
It's the difference between spending a day cleaning your own house ...
and spending every day cleaning other people's houses.
Nelson said it eloquently in this exchange:
(Robert Kaiser writes)
As we are open source, everyone can access and test that code, and
find and file the regressions, so that they get fixed over time.
(Boris Zbarsky writes)
That last conclusion doesn't necessarily follow. To get them fixed you
need someone fixing them.
(Nelson Bolyard writes)
We're very unlikely to get volunteers to spent large amounts of effort,
rewriting formerly working code to get it to work again, after it was
broken by someone else's checkin. This demotivates developers and drives
them away. They think "why should I keep working on this when others can
break my code and I must pay for their mistakes?" and "I worked hard to
get that working, and now person X has broken it. Let HIM fix it."
This was exactly how I felt,
and it's the reason I quit working on Mozilla.
A little later in the thread,
Boris Zbarsky reports that the trunk has been so broken with regressions
that it's been unusable for him for weeks or months. (When you have
someone as committed and sharp as Boris unable to use your software,
you know there's something wrong with your project's culture.)
He writes:
"For example, on my machine (Linux) about one in three SVG testcases in
Bugzilla causes trunk Gecko to hang X ..."
Justin Dolske replies, "Oh, Linux," and asks if it's related to
turning on Cairo. Boris replies affirmatively.
Just another example where a change was
checked in that caused serious regressions keeping at least one
important contributor from using the browser on a regular basis;
yet it's still there and hasn't been backed out. Of course, it's
"only Linux".
David Baron appears to take Nelson's concerns seriously,
and suggests criteria for closing the tree and making
everyone stop work to track down regressions. As he correctly
comments, closing the tree is very serious and inefficient, and should
be avoided in all but the most serious cases.
But Nelson repeats the real question:
(Nelson Bolyard writes)
Under what circumstances does a Sheriff back out a patch due to
functional regressions? From what you wrote above, I gather it's "never". :(
Alas, the thread peters out after that; there's no reply
to Nelson's question.
The problem with Mozilla isn't that there are regressions.
Mistakes happen. The problem is that regressions never get
fixed, because the project's culture encourages regressions.
The prevailing attitude is
that it's okay to check in changes that break other people's features,
as long as your new feature is cool enough or the right people want
it. If you break something, well, hey, someone will figure out a fix
eventually. Or not. Either way, it's not your problem.
Working on new features is fun, and so is getting the credit for being
the one to check them in. Fixing bugs, writing API documentation,
extensive testing -- these things aren't fun, they're hard work, and
there isn't much glory in them either (you don't get much appreciation
or credit for it). So why do them if you don't have to? Let someone
else worry about it, as long as the project lets you get away with it!
A project with a culture of responsibility would say that the person
who broke something should fix it, and that broken stuff should stay
out of the tree. If programmers don't do that
themselves just because it's the right thing to do, the project could
enforce it: just insist that regression-causing changes that can't
be fixed right away be backed out. Fix the regressions out
of the tree where they aren't causing problems for other people.
Get help from people to test it and to integrate it with those
other modules you forgot about the first time around.
Yes, even if it's a change that's needed -- even if it's something
a lot of people want. If it's a good change, there will always be time
to check it in later.
For a bit
over a year I've been running a patched version of Firefox,
which I call Kitfox,
as my main browser. I patch it because there are a few really
important features that the old Mozilla suite had which Firefox
removed; for a long time this kept me from using Firefox
(and I'm not
the only one who feels that way), but when the Mozilla Foundation
stopped supporting the suite and made Firefox the only supported
option, I knew my only choice was to make Firefox do what I needed.
The patches were pretty simple, but they meant that I've been building
my own Firefox all this time.
Since all my changes were in JavaScript code, not C++,
I knew this was probably all achievable with a Firefox extension.
But never around to it;
building the Mozilla source isn't that big a deal to me. I did it as
part of my job for quite a few years, and my desktop machine is fast
enough that it doesn't take that long to update and rebuild, then
copy the result to my laptop.
But when I installed the latest Debian, "Etch", on the laptop, things
got more complicated. It turns out Etch is about a year behind in
its libraries. Programs built on any other system won't run on Etch.
So I'd either have to build Mozilla on my laptop (a daunting prospect,
with builds probably in the 4-hour range) or keep another
system around for the purpose of building software for Etch.
Not worth it. It was time to learn to build an extension.
There are an amazing number of good tutorials on the web for writing
Firefox extensions (I won't even bother to link to any; just google
firefox extension and make your own choices).
They're all organized as step by step examples with sample code.
That's great (my favorite type of tutorial) but it left my real
question unanswered: what can you do in an extension?
The tutorial examples all do simple things like add a new menu or toolbar
button. None of them override existing Javascript, as I needed to do.
Canonical
URL to the rescue.
It's an extension that overrides one of the very behaviors I wanted to
override: that of adding "www." to the beginning and ".com" or ".org"
to the end of whatever's in the URLbar when you ctrl-click.
(The Mozilla suite behaved much more usefully: ctrl-click opened the
URL in a new tab, just like ctrl-clicking on a link. You never need
to add www. and .com or .org explicitly because the URL loading code
will do that for you if the initial name doesn't resolve by itself.)
Canonical URL showed me that all you need to do is make an overlay
containing your new version of the JavaScript method you want to
override. Easy!
So now I have a tiny Kitfox extension
that I can use on the laptop or anywhere else. Whee!
Since extensions are kind of a pain to unpack,
I also made a source tarball which includes a simple Makefile:
kitfox-0.1.tar.gz.
The new Debian Etch installation
on my laptop was working pretty well.
But it had one weirdness: the ethernet card was on eth1, not eth0.
ifconfig -a revealed that eth0 was ... something else,
with no IP address configured and a really long MAC address.
What was it?
Poking around dmesg revealed that it was related to the IEEE 1394 and
the eth1394 module. It was firewire networking.
This laptop, being a Vaio, does have a built-in firewire interface
(Sony calls it i.Link). The Etch installer, when it detected no
network present, had noted that it was "possible, though unlikely"
that I might want to use firewire instead, and asked whether to
enable it. I declined.
Yet the installed system ended up with firewire networking not only
installed, but taking the first network slot, ahead of any network
cards. It didn't get in the way of functionality, but it was annoying
and clutters the output whenever I type ifconfig -a.
Probably took up a little extra boot time and system resources, too.
I wanted it gone.
Easier said than done, as it turns out.
I could see two possible approaches.
Figure out who was setting it to eth1, and tell it to ignore
the device instead.
Blacklist the kernel module, so it couldn't load at all.
I begain with approach 1.
The obvious culprit, of course, was udev. (I had already ruled out
hal, by removing it, rebooting and observing that the bogus eth0 was
still there.) Poking around /etc/udev/rules.d revealed the file
where the naming was happening: z25_persistent-net.rules.
It looks like all you have to do is comment out the two lines
for the firewire device in that file. Don't believe it.
Upon reboot, udev sees the firewire devices and says "Oops!
persistent-net.rules doesn't have a rule for this device. I'd better
add one!" and you end up with both your commented-out line, plus a
brand new uncommented line. No help.
Where is that controlled? From another file,
z45_persistent-net-generator.rules. So all you have to do is
edit that file and comment out the lines, right?
Well, no. The firewire lines in that file merely tell udev how to add
a comment when it updates z25_persistent-net.rules.
It still updates the file, it just doesn't comment it as clearly.
There are some lines in z45_persistent-net-generator.rules
whose comments say they're disabling particular devices, by adding a rule
GOTO="persistent_net_generator_end". But adding that
in the firewire device lines caused the boot process to hang.
There may be a way to ignore a device from this file, but I haven't
found it, nor any documentation on how this system works.
Defeated, I switched to approach 2: prevent the module from loading at
all. I never expect to use firewire networking, so it's no loss. And indeed,
there are lots of other modules loaded I'd like to blacklist, since
they represent hardware this machine doesn't have. So it would be
nice to learn how.
I had a vague memory of there having been a file with a name like
/etc/modules.blacklist some time back in the Pliocene.
But apparently no such file exists any more.
I did find /etc/modprobe.d/blacklist, which looked
promising; but the comment at the beginning of that file says
# This file lists modules which will not be loaded as the result of
# alias expsnsion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
Okay, sounds like this file isn't what I wanted. (And ... hotplug? I
thought that was long gone, replaced by udev scripts.)
I tried it anyway. Sure enough, not what I wanted.
I fiddled with several other approaches before Debian diva Erinn Clark
found this helpful page.
I created a file called /etc/modprobe.d/00local
and added this line to it:
install eth1394 /bin/true
and on the next boot, the module was no longer loaded, and no longer
showed up as a bogus ethernet device. Hurray!
This /etc/modprobe.d/00local technique probably doesn't bear
examining too closely. It has "hack" written all over it.
But if that's the only way to blacklist problematic modules,
I guess it's better than nothing.
Since I'd already tried the latest Ubuntu on my desktop, I wanted to
check out Debian's latest, "Etch", on my laptop.
The installer was the same as always, and the same as the Ubuntu
installer. No surprises, although I do like the way Debian gives
me a choice of system types to install (Basic desktop, Web server,
etc. ... though why isn't "Development" an option?) compared to
Ubuntu's "take the packages we give you and deal with it later"
approach.
Otherwise, the install went very much like a typical Ubuntu install.
I followed the usual procedures and workarounds so as not to overwrite
the existing grub, to get around the Vaio hardware issues, etc.
No big deal, and the install went smoothly.
The good
But the real surprise came on booting into the new system.
Background: my Vaio SR-17 has a quirk (which regular readers will have
heard about already): it has one PCMCIA slot, which is needed for either
the external CDROM drive or a network card. This means that at any one
time, you can have a network, or a CDROM, but not both. This tends to
throw Debian-based installers into a tizzy -- you have to go through
five or more screens (including timing out on DHCP even after you've
told it that you have no network card) to persuade the installer that
yes, you really don't have a network and it's okay to continue anyway.
That means that the first step after rebooting into the new system is
always configuring the network card. In Ubuntu installs, this
typically means either fiddling endlessly with entries in the System
or Admin menus, or editing /etc/network/interfaces.
Anticipating a vi session, I booted into my new Etch and inserted the
network card (a 3COM 3c59x which often confuses Ubuntu).
Immediately, something began spinning in the upper taskbar.
Curious, I waited, and in ten seconds or so
a popup appeared informing me "You are now connected to the wired net."
And indeed I was! The network worked fine.
Kudos to debian -- Etch is the first distro which
has ever handled this automatically.
(I still need to edit /etc/network/interfaces to set my static IP
address -- network manager
Of course, since this was my laptop, the next most important feature
is power management. Happily,
both sleep and hibernate worked correctly,
once I installed the hibernate package. That had been my biggest
worry: Ubuntu was an early pioneer in getting ACPI and power
management code working properly, but it looks like Debian has
caught up.
The bad
I did see a couple of minor glitches.
First, I got a lot of system hangs in X. These turned out to be the
usual dri problem on S3 video cards. It's a well known bug, and I wish
distros would fix it!
I've also gotten at least one kernel OOPS, but I have a theory
about what might be causing that. Time will tell whether it's
a real problem.
It took a little googling to figure out the line I needed to add to
/etc/apt/sources.list in order to install programs that weren't
included on the CD.
(Etch automatically adds lines for security updates, but not for getting
new software). But fortunately, lots of other people have already asked
this in a variety of forums. The answer is:
deb http://http.us.debian.org/debian etch main contrib non-free
My husband had suggested that Etch might be lighter weight than Ubuntu
and less dependent on hal (which I always remove from my laptop,
because its
constant hardware polling
makes noise and sucks power). But no: Etch installed hal, and
any attempt to uninstall it takes with it the whole gnome desktop
environment, plus network-manager (that's apparently that nice app
that noticed my network card earlier) and rhythmbox. I don't actually
use the gnome desktop or these other programs, but it would be nice
to have the option of trying them when I want to check something out.
So for now I've resorted to the temporary solution:
mv /usr/sbin/hald /usr/sbin/hald-not
The ugly
Etch looks fairly nice, and I'm looking forward to exploring it.
I'm mostly kidding about the "ugly". I did hit one minor bit of
ugliness involving network devices which led me on a two-hour chase
... but I'll save that for its own article.
In the last installment,
I got the Visor driver working. My sitescooper process also requires
that I have a local web server (long story), so I needed Apache. It
was already there and running (curiously, Apache 1.3.34, not Apache 2),
and it was no problem to point the DocumentRoot to the right place.
But when I tested my local site,
I discovered that although I could see the text on my website, I
couldn't see any of the images. Furthermore, if I right-clicked on any
of those images and tried "View image", the link was pointing to the
right place (http://localhost/images/foo.jpg). The file
(/path/to/mysite/images/foo.jpg) existed with all the right
permissions. What was going on?
/var/log/apache/error.log gave me the clue. When I was trying to
view http://localhost/images/foo.jpg, apache was throwing this error:
[error] [client 127.0.0.1] File does not exist: /usr/share/images/foo.jpg
/usr/share/images? Huh?
Searching for usr/share/images in /etc/apache/httpd.conf gave the
answer. It turns out that Ubuntu, in their infinite wisdom, has
decided that no one would ever want a directory called images
in their webspace. Instead, they set up an alias so that any
reference to /images gets redirected to /usr/share/images.
WTF?
Anyway, the solution is to comment out that stanza of httpd.conf:
<IfModule mod_alias.c>
# Alias /icons/ /usr/share/apache/icons/
#
# <Directory /usr/share/apache/icons>
# Options Indexes MultiViews
# AllowOverride None
# Order allow,deny
# Allow from all
# </Directory>
#
# Alias /images/ /usr/share/images/
#
# <Directory /usr/share/images>
# Options MultiViews
# AllowOverride None
# Order allow,deny
# Allow from all
# </Directory>
</IfModule>
I suppose it's nice that they provided an example for how to use
mod_alias. But at the cost of breaking any site that has directories
named /images or /icons? Is it just me, or is that a bit crazy?
When we left off,
I had just found a workaround for my Feisty Fawn installer problems
and had gotten the system up and running.
By now, it was late in the day, time for my
daily Sitescooper run to grab some news to read on my Treo PDA.
The process starts with making a backup (pilot-xfer -s).
But pilot-xfer failed because it couldn't find the device,
/dev/ttyUSB1. The system was seeing the device connection --
dmesg said
[ 1424.598770] usb 5-2.3: new full speed USB device using ehci_hcd and address 4
[ 1424.690951] usb 5-2.3: configuration #1 chosen from 1 choice
"configuration #1"? What does that mean? I poked around /etc/udev a
bit and found this rule in rules.d/60-symlinks.rules:
# Create /dev/pilot symlink for Palm Pilots
KERNEL=="ttyUSB*", ATTRS{product}=="Palm Handheld*|Handspring *|palmOne Handheld", \
SYMLINK+="pilot"
Oh, maybe they were calling it /dev/pilot1? But no, there was nothing
matching /dev/*pilot*, just as there was nothing matching
/dev/ttyUSB*.
But this time googling led me right to the bug,
bug
108512. Turns out that for some reason (which no one has
investigated yet), feisty doesn't autoload the visor module when
you plug in a USB palm device the way other distros always have.
The temporary workaround is sudo modprobe visor;
the long-term workaround is to add visor to /etc/modules.
On the subject of Feisty's USB support, though, I do have some good
news to report.
My biggest motivation for upgrading from edgy was because USB2 had
stopped working a few months ago --
bug 54419.
I hoped that the newer kernel in Feisty might fix the problem.
So once I had the system up and running, I plugged my trusty
hated-by-edgy MP3 player into the USB2 hub, and checked dmesg.
It wasn't working -- but the error message was actually useful.
Rather than obscure complaints like
end_request: I/O error, dev sde, sector 2033440
or
device descriptor read/64, error -110
or
3:0:0:0: rejecting I/O to dead device
it had a message (which I've since lost) about "insufficient power".
Now that's something I might be able to do something about!
So I dug into my bag o' cables and found a PS/2 power adaptor that
fit my USB2 hub, plugged it in, plugged the MP3 player into the hub,
and voila! it was talking on USB2 again.
I finally found some time to try the latest Ubuntu, "Feisty Fawn", on
my desktop machine.
I used a xubuntu alternate installer disk, since I don't need the
gnome desktop, and haven't had much luck booting from the Ubuntu
live CDs lately. (I should try the latest, but my husband had already
downloaded and burned the alternate disk and I couldn't work up the
incentive to download another disk image.
The early portions of the install were typical ubuntu installer:
choose a few language options, choose manual disk partitioning,
spend forever up- and down-arrowing through the partitioner trying
to persuade it not to automount every partition on the disk (after
about the sixth time through I gave up and just let it mount the
partitions; I'll edit /etc/fstab later) then begin the install.
Cannot find /lib/modules/2.6.20-15-generic
update-initramfs: failed for /boot/initrd.img-2.6.0-15-generic
Couldn't install grub, and warning direly, "This is a fatal error".
But then popcorn on #linuxchix found
Ubuntu
bug 37527. Turns out the problem is due to using an existing /boot
partition, which has other kernels installed. Basically, Ubuntu's
new installer can't handle this properly. The workaround is to
go through the installer without a separate /boot partition, let it
install its kernels to /boot on the root partition (but don't let it
install grub, even though it's fairly insistent about it), then reboot
into an old distro and copy the files from the newly-installed feisty
partition to the real /boot. That worked fine.
The rest of the installation was smooth, and soon I was up and
running. I made some of my usual tweaks (uninstall gdm, install tcsh,
add myself to /etc/password with my preferred UID, install fvwm and
xloadimage, install build-essentials and the zillion other packages
needed to compile anything useful) and I had a desktop.
Of course, the adventure wasn't over. There was more fun yet to come!
But I'll post about that separately.
The previous entry covered springtime butterflies, but
it's springtime in the back yard, too.
Notch
(our longtime resident squirrel) is heavily pregnant. It's not slowing
her down much -- she still leaps and climbs gracefully -- but
apparently raging hormones in a pregnant squirrel
create a desperate need to bury walnuts. She's here all day long,
demanding one walnut after another. She isn't very interested in
eating, only burying.
We play games. Today I handed her a walnut then raised
it while she was still holding it; she hung on for a few seconds, then
pulled her hind legs up, did a backflip, landed on her forelegs and
scampered off, to reappear a few minutes later wanting another one.
Ringtail the fox squirrel is still with us, as is a young male Eastern
grey (perhaps the father of Notch's brood?) and the most recent
arrival, a male fox squirrel.
But in addition, we have a new visitor
we've only seen a few times: a mouse, larger than a house mouse but
smaller than a black rat. It's apparently some kind of native mouse.
(Good! That's much more interesting, plus it means it's far less
likely to want to move inside the house. Wildlife is great fun
outdoors, less fun when they want to move in with you.)
So what kind of mouse is it?
Hey, no problem -- there are only thirty or forty species of native
mouse in my mammals field guide! Okay, so identifying a mouse that you
only see for a few seconds at a time isn't terribly easy. But one
caught my eye pretty early on: the
brush mouse
with its long ears and habit of moving by jumping, like our mouse.
I don't know for sure that this is a brush mouse, but it seems
like a reasonable first guess.
When I google for "brush mouse", the links aren't that useful,
but the ads are intriguing.
Google presents two sponsored ads. One is a colored ad
at the top of the page for a Mouse Brush, from
ThatPetPlace.com. I know someone who keeps mice -- I'll have
to ask her if she has a Mouse Brush. I thought they normally kept
themselves clean pretty well without needing to be brushed, but you
never know, maybe those fancy longhaired mice need some help.
The second ad was over on the right and was even more interesting.
It said:
Brush Mouse
Great deals on Brush Mouse
Shop on eBay and Save! www.eBay.com
That's a relief -- if anything happens to our brush mouse, now
we know where we can get a new one!
It's just amazing the sorts of things you can find on ebay.
It's spring, and butterflies are everywhere in the local parks.
If you like butterflies and live in Northern California (or anywhere
with a similar climate), get yourself out this weekend ot check out
the action!
There are a few northern checkerspots, tiger swallowtails and others
flitting about, but the real partiers are the variable checkerspots.
At Stevens Creek, they're clustered in huge numbers on the pale
blue-violet flowers of yerba santa. Some yerba santa bushes are
completely covered with butterflies. Others aren't: a closer look
shows that those bushes have flowers pointing down, rather than up.
Maybe once a flower is pollinated and its nectar gone, it sags?
On the other side of the road, at Piccheti Ranch, yerba santa isn't
so common, and the checkerspots gather on the last of the clusters of
buckeye flowers.
For quite some time, I've been seeing all too frequently the dialog
in Firefox which says:
A script on this page may be busy, or it may have stopped
responding. You can stop the script now, or continue to see if the
script will complete. [Continue] [Stop script]
Googling found lots of pages offering advice on how to increase the
timeout for scripts from the default of 5 seconds to 20 or more
(change the preference dom.max_script_run_time in
about:config. But that seemed wrong. I was seeing the
dialog on lots of pages where other people didn't see it, even
on my desktop machine, which, while it isn't the absolute latest
and greatest in supercomputing, still is plenty fast for basic
web tasks.
The kicker came when I found the latest page that triggers this
dialog: Firefox' own cache viewer. Go to about:cache and
click on "List Cache Entries" under Disk cache device.
After six or seven seconds I got an Unresponsive script dialog
every time. So obviously this wasn't a problem with the web sites
I was visiting.
Someone on #mozillazine pointed me to Mozillazine's page
discussing this dialog, but it's not very useful. For instance,
it includes advice like
To determine what script is running too long, open the Error Console
and tell it to stop the script. The Error Console should identify
the script causing the problem.
Error console? What's that? I have a JavaScript Console, but it
doesn't offer any way to stop scripts. No one on #mozillazine
seemed to have any idea where I might find this elusive Error
console either. Later Update: turns out this is new with Firefox 2.0.
I've edited the Mozillazine page to say so. Funny that no one on
IRC knew about it.
But there's a long and interesting
MozillaZine discussion of the problem
in which it's clear that it's often caused by extensions
(which the Mozillazine page had also suggested).
I checked the suggested list of Problematic
extensions, but I didn't see anything that looked likely.
So I backed up my Firefox profile and set to work, disabling my
extensions one at a time. First was Adblock, since it appeared
in the Problematic list, but removing it didn't help: I still got
the Unresponsive script when viewing my cache.
The next try was Media Player Connectivity. Bingo! No more
Unresponsive dialog. That was easy.
Media Player Connectivity never worked right for me anyway.
It's supposed to help with pages that offer videos not as a simple
video link, like movie.mpeg or movie.mov or whatever,
but as an embedded object in the page which insists on a
specific browser plug-in
(like Apples's QuickTime or Microsoft's Windows Media Player).
Playing these videos in Firefox is a huge pain in the keister -- you
have to View Source and crawl through the HTML trying to find the URL
for the actual video. Media Player Connectivity is supposed to help
by doing the crawl for you and presenting you with video links
for any embedded video it finds. But it typically doesn't find
anything, and its user interface is so inconsistent and complicated
that it's hard to figure out what it's telling you. It also can't
follow the playlists and .SMIL files that so many sites use now.
So I end up having to crawl through HTML source anyway.
Too bad! Maybe some day someone will find a way to make it easier
to view video on Linux Firefox. But at least I seem to have gotten
rid of those Unresponsive Script errors. That should make for nicer
browsing!
"Would you take a look at this?" my husband asked. I glanced over --
he was on the Gnome desktop on his newly-installed Debian Etch system,
viewing some of his system icons with
pho.
Specifically, an xchat icon, an X with some text across it.
"So?" I shrugged.
He pointed to his panel. "But it's really using that icon."
A little yellow happy-face-with-blob thing.
He right-clicked on the panel icon and brought up a dialog.
"See, it should be using /usr/share/pixmaps/xchat.png.
Now, I run pho /usr/share/pixmaps/xchat.png ..."
And sure enough, the image it said it was using wasn't the image
it was actually putting in the panel.
That jogged a memory. "That happened to me once back when I used
Gnome. Try a locate xchat | grep png.
I think it was using an icon from somewhere else -- that might find
it for you."
Sure enough, there were several xchat png images on his system.
I suggested going one step further, and actually viewing all of them:
pho `locate xchat | grep png`
We stepped through the images, and sure enough, we found the
icon he was seeing.
It was at /usr/share/icons/gnome/32x32/apps/xchat.png (with a larger
sibling at /usr/share/icons/gnome/48x48/apps/xchat.png).
Good of Gnome to pretend let the user customize the icon location,
even though it actually doesn't bother to use the icon specified
there! At least you get a nice feeling of empowerment from pretending
to choose the icon.
Later in the day, continuing to fiddle with the desktop settings,
Dave burst out laughing. "You've got to see this. It's so Gnome."
When I saw it, I had to laugh too. You may think you know
what you want, but Gnome knows better! If you've ever tried to
customize Gnome, you'll laugh, too, when you see the short video
we took of it:
Gnome knows
best (764K).
My laptop has always been able to sleep (suspend to RAM), one way
or another, but I had never managed it on a desktop machine.
Every time I tried running something like
apm -s, apm -S, echo 3 >/sys/power/state, or Ubuntu's
/etc/acpi/sleep.sh, the machine would sleep nicely, then when I
resumed it would come up partway then hang, or would simply boot
rather than resuming.
Dave was annoyed by it too: his Mac G4 sleeps just fine, but none
of his Linux desktops could. And finally he got annoyed enough to
spend half a day playing with different options. With what he
learned, both he and I now have desktops that can suspend to RAM
(his under Debian Sarge, mine under Ubuntu Edgy).
One step was to install hibernate (available as
a deb package in both Sarge and Edgy, but distros which don't offer
it can probably get it from somewhere on suspend2.net).
The hibernate program suspends to disk by default (which
is what its parent project, suspend2, is all about) but it
can also suspend to RAM, with the following set of arcane arguments:
hibernate -v 4 -F /etc/hibernate/ram.conf
(the -v 4 adds a lot of debugging output; remove it once
you have things working).
Though actually, in retrospect I suspect I didn't need to install
hibernate at all, and Ubuntu's /etc/acpi/sleep.sh script would
have done just as well, once I'd finished the other step:
Fiddle with BIOS options. Most BIOSes have a submenu named something
like "Power Management Options", and they're almost always set wrong
by default (if you want suspend to work). Which ones are wrong
depends on your BIOS, of course. On Dave's old PIII system, the
key was to change "Sleep States" to include S3 (S3 is the ACPI
suspend-to-RAM state). He also enabled APM sleep, which was disabled
by default but which works better with the older Linux kernels he
uses under Sarge.
On my much newer AMD64 system, the key was an option to "Run VGABIOS
if S3 Resume", which was turned off by default. So I guess it wasn't
re-enabling the video when I resumed. (You might think this would
mean the machine comes up but doesn't have video, but it's never
as simple as that -- the machine came up with its disk light solid
red and no network access, so it wasn't just the screen that was
futzed.)
Such a simple fix! I should have fiddled with BIOS settings long
ago. It's lovely to be able to suspend my machine when I go away
for a while. Power consumption as measured on the Kill-a-Watt
goes down to 5 watts, versus 3 when the machine is "off"
(desktop machines never actually power off, they're always sitting
there on standby waiting for you to press the power button)
and about 75 watts when the machine is up and running.
Now I just have to tweak the suspend scripts so that it gives me a
new desktop background when I resume, since I've been having so much
fun with my random
wallpaper script.
Later update: Alas, I was too optimistic. Turns out it actually only
works about one time out of three. The other two times, it hangs
after X comes up, or else it initially reboots instead of resuming.
Bummer!
Dave and I just got back from another road trip. We saw some fabulous
stuff, but today's entry is on ways to amuse yourself during
long hours on the road.
One way to start is to make fun of the grandiose names on RVs, as well
as the mandatory swoopy graphics (we saw only one swoopless RV on the
whole trip -- it had plain straight stripes on the side).
RVs almost always have several names, and there are so many different
models you can get through a whole road trip without ever seeing a
repeat. One of our favorites from this trip was "Puma, by Palomino",
a rather odd combination. I wouldn't expect a puma and a palomino
to get along very well or have much in common. I guess they're both
sort of golden in color (which the RV in question was not). The
graphic was of a puma, not a palomino.
Small-town roadside signs can be fun, too. Of course, they tend to be
riddled with spelling and punctuation errors, which is half the fun.
We couldn't figure out what they were aiming at with the punctuation
on the sign for HOLE N"THE ROCK, a few miles south of
Moab. Why a double quote rather than an apostrophe? Or is it supposed
to be two apostrophes together? And what is it doing there after the N?
An apostrophe before the N could stand for the letter I, but after it
... it's hard to tell what it's standing for, except the missing space
before the next word, THE. We spent a while trying to come up with
three-letter words beginning with N which would make sense between
HOLE and THE ROCK, but then some more amazing Moab scenery appeared
and we lost interest in the punctuation game.
But small towns can have a lot to offer, too. Sometimes you can
learn all sorts of things that might not be available in the big city.
We saw a sign on a roadside church in Bakersfield advertising their
upcoming Creation Seminar. Wow! I didn't know mere mortals could
learn how to do that stuff too! I wish I'd had time to stick around
for the seminar.
Other times small towns are just scary.
The Bullberry Inn Bed & Breakfast in Tropic, UT has a sign out front
proclaiming that it's the "Home of Granny's Bullberry Jelly".
I've heard of horse apples, but I'm not sure I want to know what
a bull berry is, let alone spread it on my toast. We opted to stay
in one of the other hotels instead.
The wireless network was messed up at the Super-8.
No surprise there -- Super-8 motels always have flaky wireless.
But last night's wi-fi travails were quite a bit more interesting
than the usual story.
When we checked in, the sign
at the desk saying "We know the wi-fi is flaky;
you've been warned, no refunds", wasn't encouraging.
We needed some information from the web fairly quickly,
so rather than futz with trying to get the motel system to work we
headed over to the public library, where I got re-acquainted with the
travails of browsing circa 1999 by using their slow link and
Internet Explorer. How do people live without being able to open
lots of search results in multiple tabs? And hitting return didn't
work in any search fields. Eesh.
I was also amused to find that when I searched on terms related to IRS
and tax information, several of the results brought up a page saying
they were blocked by the library's firewall. Wouldn't want anyone
looking at that sort of smut on public library machines!
Anyway, after dinner we had time to fiddle with the hotel wi-fi.
When we couldn't get a reliable signal in the room,
we carted our laptops down to the lobby to see if things were
better there. They weren't.
But the single public lobby workstation was free (showing a
myspace page), so we decided to try that and see if it worked any
better than our laptops. Nope.
But something about the throbber in the lobby workstation's browser
seemed familiar to me. That's not IE ... it's not firefox either ...
Why, it's konqueror! But ... doesn't that mean ...?
We tried browsing to a few familiar file paths, like /etc/fstab,
and sure enough, the lobby workstation was running linux (Slackware).
We played filename guessing games for a bit before discovering
Tools->Open Terminal. That wasn't very reliable, though --
it seemed to have a redraw problem and it was hard to get past that.
(Later I found an alternative elsewhere in the Konqueror menus,
"Show Terminal Emulator". I'm not clear on why Konqueror needs two
different terminal emulators, but it was helpful here.)
Then I experimentally typed "whoami" and
discovered that we were root. How handy!
It turned out that the machine was running a live CD based distro.
Dave stumbled on /etc/issue, which began with the lines:
-------------------------------------------------------
:: WHAX 1.0 -- Dev Edition: http://www.iwhax.net
-------------------------------------------------------
User : root
Pass : toor
If you use this CD not for development purposes, remember to change
passwords!
Great fun! And we played around with the machine for a bit.
But alas, none of this helped with the net -- the WHAX box was just as
much a victim of the network as we were.
After a brief delay to admire the bright yellow Sunbeam Alpine that
pulled up on a trailer outside the registration desk (the folks
playing poker at the next table had never seen a Sunbeam before),
Dave took to the parking lot with his laptop looking for a
stronger signal. (He can do this with his Prism2 card while I can't
with my Prism54. Why is it that every Linux wi-fi driver
has a completely different set of supported operations?)
Does it still count as war-walking if you're just looking for a
working connection for a net you've paid for?
He found the strongest signal at the Travelodge next door (the net is
shared between the two motels), just outside the metal door marked
"DISCONNECT MAIN ELECTRIC".
I guess whoever set up this network decided
that the perfect place to put a radio transmitter was in the electric
main box surrounded by lots of metal and current-carrying wires.
Not being an RF engineer myself, somehow that would not have occurred
to me as the ideal spot. But what do I know?
Every time I do a system upgrade on my desktop machine,
I end up with a web server that can't do PHP or CGI,
and I have to figure out all over again how to enable all the
important stuff. It's all buried in various nonobvious places.
Following Cory Doctorow's
"My
blog, my outboard brain" philosophy,
I shall record here the steps I needed this time, so next time I can
just look them up:
Install apache2.
Install an appropriate mod-php package (or, alternately, a full fledged
PHP package).
Edit /etc/apache2/sites-enabled/000-default, find the stanza
corresponding to the default site, and change AllowOverride
from None to something more permissive. This controls what's
allowed through .htaccess files. For testing, use All;
for a real environment you'll probably want something
more fine grained than that.
While you're there, look for the Options line in the same stanza
and add +ExecCGI to the end.
Edit /etc/apache2/apache2.conf and search for PHP. No, not
the line that already includes index.php; keep going to the lines
that look something like
Uncomment these. Now PHP should work. The next step is to enable CGI.
Still in /etc/apache2/apache2.conf, search for CGI.
Eventually you'll get to
# To use CGI scripts outside /cgi-bin/:
#
#AddHandler cgi-script .cgi
Uncomment the AddHandler line.
Finally, disable automatic start of apache at boot time (I don't
need a web server running on my workstation every day, only on days
when I'm actually doing web development). I think some upcoming Ubuntu
release may offer a way to do that through Upstart, but for now, I
mv /etc/init.d/apache /etc/noinit.d
(having previously created /etc/noinit.d for that purpose).
Pho 0.9.5-pre5
has been working nicely since I released it two weeks
ago. And meanwhile, I've already started working on the next
version. So I've released it as 0.9.5 with no changes (except for
version string and some updates to the documentation and debian
config files).
I made a .deb on Ubuntu Edgy, but haven't actually tested it yet
(anyone who sees problems, please let me know) and I'll try to
make a straight Debian package on Sarge sometime soon.
So what's this stuff I've been working on for the next version?
Image categorization. I shoot so many photos, and categorizing
them by keyword can be a lot of work. Although
Pho's "Notes 0 through 9" are helpful for a small number of notes,
it's tough keeping track of which note corresponds to which keyword
when I'm categorizing a directory full of photos from a trip.
The next Pho release (which will have a much shorter release cycle
than 0.9.5 did, honest!) will have an optional Keywords dialog
where you can type in keywords and associate them with photos.
I know there are apps such as f-spot, gthumb and Picasa, but they
all seem much more heavyweight than what I need, and Pho only
needs a tiny bit of work to get there.
While I'm working on dialogs, I'm also cleaning up modality:
Pho dialogs will now stay visible so they can't get lost behind
the image, and the question dialog ("Really delete?" or "Do you want
to quit?" will be modal.
But that's all coming in the next version.
For now, 0.9.5 is the stable version: get it from
the Pho page.
I opened the paper and immediately noticed the ad at right.
The ad doesn't include any plot details,
but I didn't need them after seeing the ad.
Obviously this must be a movie about two children
who boldly install Debian Linux on the family PC, and the
adventures that ensue.
Indeed, a check of the official web site --
which I can only read with View Page Source because
otherwise all I see is whines about needing Flash 8 --
contains the following synopsis:
Based on the acclaimed science fiction short story by Lewis
Padgett, The Last Mimzy tells the story of two children
who discover a mysterious box that contains some strange devices
they think are toys. As the children play with these 'toys,' they
begin to display higher and higher intelligence levels. Their
teacher tells their parents that they seem to have grown beyond
genius.
Cool, finally a Linux movie!
(You can see the Debian logo at Wikimedia
if you're not already familiar with it.)
Carla Schroder's latest (excellent) article,
Cheatsheet:
Master Linux Package Management,
spawned a LinuxChix discussion of the subtleties of Debian package
management (which includes other Debian-based distros such as
Ubuntu, Knoppix etc.)
Specifically, we were unclear on the differences among apt-get
upgrade or dist-upgrade,
aptitude upgrade, aptitude dist-upgrade,
and aptitude -f dist-upgrade.
Most of us have just been typing whichever command we learned first,
without understanding the trade-offs.
But Erinn Clark, our Debian Diva, checked with some of her fellow
Debian experts and got us most of the answers, which I will attempt
to summarize with a little extra help from web references and man pages.
First, apt-get vs. aptitude:
we were told that the primary difference between them is
that "aptitude is less likely to remove packages." I confess
I'm still not entirely clear on what that means, but aptitude is seen
as safer and smarter and I'll go on using it.
aptitude upgrade gets updates (security, bug fixes or whatever)
to all currently installed packages. No packages will be removed,
and no new packages will be installed.
If a currently installed package changes to require a
new package that isn't installed, upgrade will refuse to update
those packages (they will be "kept back"). To install the "kept back"
packages with their dependencies, you can use:
aptitude dist-upgrade gets updates to the currently installed
packages, including any new packages which are now required.
But sometimes you'll encounter problems in the dependencies,
in which case it will suggest that you:
aptitude -f dist-upgrade tries to "fix broken packages",
packages with broken dependencies. What sort of broken dependencies?
Well, for example, if one of the new packages conflicts with another
installed package, it will offer to remove the conflicting package.
Without -f, all you get is that a package will be "held back" for
unspecified reasons, and you have to go probing with commands like
aptitude -u install pkgname or
apt-get -o Debug::pkgProblemResolver=yes dist-upgrade
to find out the reason.
The upshot is that if you want everything to just happen in
one step without pestering you, use aptitude -f dist-upgrade;
if you want to be cautious and think things through at each step,
use aptitude upgrade and be willing to type the stronger
commands when it runs into trouble.
Sections 6.2 and 6.3 of the
Debian
Reference cover these commands a little, but not in much detail.
The APT
Howto is better, and runs through some useful examples (which I
used to try to understand what -f does).
Thanks go to Erinn, Ari Pollak, and Martin Krafft (whose highly rated book,
The
Debian System: Concepts and Techniques, apparently would have
answered these questions, and I'll be checking it out).
Holder's County Inn, a local diner chain, has new menus.
All dinner entrees now come with choice of soup or salad,
fresh vegetables, and "appropriate starch."
Invoking Dave Barry, I thought, wouldn't that be a great
name for a band?
Or perhaps a phrase to save for fiction writing. "Sir," she replied
with appropriate starch, "your participles are dangling."
Pho's been static for a long time -- it's been working well enough
that I keep forgetting that there were a couple of bugs that need
fixing for a 0.9.5 release.
I had some time tonight, so I dug in and fixed the bugs I
remembered: some issues with zooming in and out, a bug with
aspect ratio when switching out of fullscreen mode, and
the fact that Note 0 didn't work.
While I was at it, I added an environment variable, PHO_ARGS,
where you can preset your default values. I find that I always
want -p (presentation mode), so now I can specify that with
PHO_ARGS=p, and use pho -P when I want window borders.
I also updated the man page.
I'll test this for a little while and if nobody finds any
serious bugs, maybe I can finally release 0.9.5.
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.)
Australia! I spent the last week in Sydney as a speaker for
linux.conf.au 2007. My first time overseas, and first time in way
too long at a technical Linux conference.
I had lots of plans to write about it as it was happening. Jot down
events of the day, impressions of the talks, etc. In retrospect I have
no idea how anyone manages to do that. There's just so much
stuff going on at LCA that I was busy the whole time.
Blogging or sleep ... that might be a hard choice for some people, but
I like sleep. Sleep is good. Sleep lets me have a lot more fun at the
talks and the social events afterward.
First, about technical conferences. With the emphasis on technical.
In California we have a bunch of conferences like Linux World Expo and
the O'Reilly Emerging Tech conference, where a few
geeks-turned-PR-people make whizzy presentations to marketing and CIO
sorts. Ick. Sometimes there are a few presentations that are actually
technical, but not many. And oh, did I mention the multi-kilobuck reg
fees?
Linux.conf.au isn't like that at all. It's all geeks, all the time.
Not everyone is a programmer (though the majority are), but of the
hundreds of people I talked to during the week of the conference I
didn't meet a single person who wasn't deeply and passionately
involved with Linux in some way. You could pick any person at random,
start a conversation and immediately be deep in conversation about
interesting details of some aspect of Linux you hadn't thought much
about before.
Picking people at random and talking to them? What sort of a geek
would do that? Well, the cool thing is that in an environment like
LCA, the shyest geek can still network pretty well. If you can't
make small talk or force a fake smile, you can jump to the meaty
stuff right away and start trading notes on filesystems or network
configuration or IRQs or python GUI toolkits. I was almost late to
the post-conference LinuxChix meetup because it turned out the person
sitting next to me at breakfast was a udev expert who knew how to get
my memory stick reader recognized (more on that in a separate article).
Not that you'd really need to talk to random people if you didn't want
to. One of the many highlights of the conference was the chance to
meet people from all over the world whom I'd only met before on IRC
or mailing lists. I already "knew" lots of people there, even if I'd
never seen their faces before.
There were tons of
talks, with four or five tracks going at all
times, and all on good topics. It was quite common to want to go to
two or three or even more simultaneous presentations. Fortunately
nearly everything was video taped, so with any luck we'll be able to
catch up on sessions that we missed (and folks who couldn't afford the
trip can benefit from all the great talks). The videos are still being
uploaded and aren't all there yet, but they've done an amazing job
getting as many transcoded and uploaded as they have so far, and I'm
sure the rest won't be too far behind. (Some of them are on the
mirror
but not yet linked from the Schedule page.)
How do they get all those great talks? I must say, LCA treats its
speakers well. In addition to the super-secret "Speakers Adventure",
which we were assured was worth getting up at 6am for (it was),
they gave us a dinner cruise on scenic Sydney harbor, which
included an after-dinner talk on how to give better talks (focused on
flash rather than content). I didn't agree with all his points, but
that's okay, the point is to get people thinking. I bet every one of
us (certainly everyone I talked to) went back and revised our talks at
least a little bit based on the presentation.
I hope my GIMP
tutorial and my miniconf bugfixing talk lived up to
the organizing committee's expectations -- it's intimidating sharing a
schedule with so many smart people who are also good speakers!
The first two days of the conference were taken up by
"miniconfs".
I originally had my eyes on several of the miniconfs, on topics such
as Kernel, Education and Research, though I knew I'd start the day at the
LinuxChix
miniconf.
As it turned out, that miniconf was so excellent that I spent
the whole day there. It included a mixture of technical and social
issues: talks on women in FOSS (Sulamita), my talk on "Bug Fixing for
Non Programmers", "Demystifying PCI" (Kristin), a set of terrific
"Lightning Talks" under five minutes, and eventually concluded with
talks on networking in the social sense (Jacinta) and negotiating
wages (Val). After Jacinta's and Val's talks we broke up into small
groups and headed for the lawn outside for some very productive
discussions of networking and negotiation, which were so interesting
we kept the discussions going all afternoon.
The LinuxChix miniconf was Standing Room Only all day, with plenty of
men listening in. It was quite a rush to see so many technical women
all together, giving talks and discussing details of Linux and FOSS.
Another miniconf-like activity was Open Day, on Thursday afternoon,
when the conference invited people from the area (particularly
teachers and students) to wander through displays on all sorts of FOSS
topics. There were booths from most of the major distros handing out
CDs or inviting people to do network installs, a booth showing the One
Laptop Per Child project, booths showing games
and interesting projects such as amateur rocket and satellite projects
or the open source Segway clone, a Linuxchix booth, and booths from a
few companies such as Google. Open Day was jam packed, people seemed
to be having fun and they gave away a few amazing prizes, like Vaio
laptops (donated by IBM) which came in an amazingly small box. I was
itching to see what was in those little boxes (we never get the cool
small laptops in the US, where the national philosophy is "Bigger is
Better") but alas, I wasn't one of the lucky winners.
A couple of other notable talks I went to:
Making Things Move:
Finding Inappropriate Uses for Scripting Languages by Jonathan
Oxer, which included live demos of hooking up radio switches and
controlling them from the commandline (with a little simple C glue);
and "burning cpu and
battery on the gnome desktop" by Ryan Lortie, who not only gave an
excellent and entertaining list of programs and services which use up
system resources inefficiently by polling, opening too many files or
other evils (several other speakers offered similar lists), but also
gave concrete advice for finding such programs and fixing them.
I'm looking forward to seeing his slides uploaded (I'll link them
here when I find them).