Shallow Thoughts

How to set your time zone

My laptop's clock has been drifting. I suspect the clock battery is low (not surprising on a 7-year-old machine). But after an hour of poking and prodding, I've been unable to find a way to expose the circuit board under the keyboard, either from the top (keyboard) side -- though I know how to remove individual keycaps, thanks to a reader who sent me detailed instructions a while back (thanks, Miles!) -- or the bottom. Any expert on Vaio SR laptops know how this works?

Anyway, that means I have to check and reset the time periodically. So this morning I did a time check and found it many hours off. No, wait -- actually it was pretty close; it only looked like it was way off because the system had suddenly decided it was in UTC, not PDT. But how could I change that back?

I checked /etc/timezone -- sure enough, it was set to UTC. So I changed that, copying one from a debian machine -- "US/Pacific", but that didn't do it, even after a reboot.

I spent some time reading man hwclock -- there's a lot of good reading in that manual page, about the relation between the system (kernel) clock and the hardware clock. Did you know that you're not supposed to use the date command to set the system time while the system is running? Me neither -- I do that all the time. Hmm. Anyway, interesting reading, but nothing useful about the system time zone.

It has an extensive SEE ALSO list at the end, so I explored some of those documents. /usr/share/doc/util-linux/README.Debian.hwclock is full of lots of interesting information, well worth reading, but it didn't have the answer. man tzset sounded promising, but there was no such man page (or program) on my system. Just for the heckofit, I tried typing tz[tab] to see if I had any other timezone-related programs installed ... and found tzselect. And there was the answer, added almost as an afterthought at the end of the manual page:

Note that tzselect will not actually change the timezone for you. Use 'dpkg-reconfigure tzdata' to achieve this.

Sure enough, dpkg-reconfigure tzdata let me set the time zone. And it even seems to be remembered through a reboot.

Tags: linux, debian, ubuntu, vaio
[ 10:04 May 16, 2008    More linux | link to this entry ]

Oak wants to be a quail, or maybe a wren

The young mockingbird fledgelings have decided they like us. Oak in particular took a liking to our backyard, and particularly the lawn. It seems he wants to be a quail when he grows up: he loves to run (not hop) around the yard, and flies only when threatened (though once he gets going, he flies quite competently). When he's not being a quail he practices being a wren, cocking his tail up the way wrens do. I managed to get couple of pictures of Oak.

Cedar likes the backyard too, but stays above ground in the chinquapin or the orange tree. In the evenings, they sing a duet, somewhat lower EEPs from Cedar and higher ones from Oak (Oak can sing two notes, but when Cedar's singing Oak takes the soprano line). Holly remains in the front yard, a distant third EEP.

Meanwhile, I've finally managed to attract some goldfinches to the thistle sock hanging outside the office window. Photos (not good ones) here.

Tags: nature, birds, urban wildlife
[ 20:46 May 12, 2008    More nature/birds | link to this entry ]

Feeding Fledgelings

After I wrote about the mockingbird fledgelings the other day, someone asked me how long the parents keep feeding them. I checked past blog entries -- that year they fledged on June 25, were still being fed on July 10 and were still EEPing but no longer being fed on July 20. A little over two weeks.

Two of this year's chicks, who fledged four days ago, can fly pretty well now for short bursts, but they tire very quickly and can't stay up for a long flight.

Just now, at sunset, Oak (I'm naming them for to the trees they ended up in when they fledged) flew from the oak over to the back porch roof and spent ten or fifteen minutes begging from there, in nice view of my office window. He was EEPing louder than the other chicks, and both parents were feeding him as fast as they could find bugs. Oak is as big as a towhee, and fat and fluffy, with a spotted breast and a short stubby tail less than two inches long. He still has some of that scrowly wide yellow bill that says "Feed me, mama!"

At one point a parent showed up with a pyracantha berry, but Oak was already being fed. The parent tried a little squawk, maybe to see if Cedar wanted anything, but almost dropped the berry in the process. So with an air of "oh, what the heck!" it swallowed the berry.

Then Cedar started crying from the chinquapin (or whatever the weird tree in the backyard is) and drew the parents' attention away from Oak. After another few minutes of fruitless eeping Oak decided to get some of that action and joined Cedar. Then they both flew down to the lawn, where for the first time I could see both at the same time. Cedar is a lot slimmer than Oak, but with a longer tail, maybe half the length of an adult's.

Oak was in the wildflower bed, actively hunting for food and occasionally finding something to swallow, though I don't have a lot of confidence that they were insects rather than dirt clods. Cedar wasn't hunting for food very actively, but took a few desultory pecks at the pavement and once picked up and swallowed something (a piece of a leaf, I think). Every now and then one parent would glide in from the front yard, and whichever chick noticed it first and eeped would get fed.

I haven't seen Holly today. I thought I heard some eeping from the direction of the holly in the front yard, but never definitely located the third chick.

The evening wore on, though, and the chicks have found trees to roost in for the night and have finally stopped eeping. Mom is taking a well-deserved break while Dad sings the family a lullaby.

Tags: nature, birds, urban wildlife
[ 21:00 May 08, 2008    More nature/birds | link to this entry ]

Chicks everywhere

It's definitely spring now! The air is filled with the cheeping of baby birds demanding feeding.

I thought we didn't have a nesting mockingbird pair this year, because there's been almost no singing. I've heard chicks cheeping from the yard across the street, but nothing in our yard.

Until today, that is. This morning, there's a mocker chick in the holly tree in the front yard and another one in the red oak in the back yard, both making noisy demands to be fed. The parents are having a hard time, between hunting and flying back and forth between the two chicks.

The chicks are staying too high up for any good photos, but they're easy to see in binoculars. They're a bit bigger than house sparrows, but still very baby-like, with short tails, fluffy spotted downy chests and big wide yellow bills. They can flutter from branch to branch pretty well, but aren't comfortable going farther than that, especially on this windy morning. I wonder if the wind explains how the two fledgelings ended up in trees so far apart?

(Update a couple of days later: turns out there are actually three chicks. One of them is confident enough to fly in the open and perch on power lines; the other two haven't moved from their respective trees.)

I'm hearing lots of California towhee pings, too (they make a noise like a submarine sonar ping) and there's a towhee pair foraging more actively than usual in the garden, so I'm pretty sure there are some towhee chicks somewhere nearby, getting ready to fledge.

After watching the fledgelings in the yard for a while, I decided to take a peek at some Peregrine falcon webcams. The IndyStar falcon-cam is easy -- two views to choose from, and it pops up a window with an image that refreshes every 30 seconds. Works everywhere. The San Jose falcon-cam is a lot trickier, since their page is loaded with elaborate "pop up the Microsoft Windows Media Player plug-in, and if you don't have that, you're out of luck" code. But Sarah and I and some folks in #linuxchix worked it out a few months ago before there was much to see: it's actually a Realplayer stream, which realplay itself can't play but vlc sometimes can: vlc rtsp://bird-mirror.ucsc.edu/birdie-sj.sdp

It doesn't work every time -- I have to try it five or six times before I get anything. I'm told that this is a common problem -- RTSP streams are notorious for having problems with NAT, so if you're anywhere behind a firewall, keep cheeping with vlc and eventually the server will feed you some falcon images.

Tags: nature, birds, urban wildlife
[ 12:24 May 04, 2008    More nature/birds | link to this entry ]

Two font mysteries solved

This has been a good week for fonts: two longstanding mysteries solved.

The first concerns the bitstream vera sans mono I've been using as a terminal font in apps like rxvt and xterm. I'd been specifying it in ~/.Xdefaults like this:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso10646-1

The mystery is that I'd noticed that in xterm, the font looked slightly different -- slightly uglier -- than in rxvt (both apps use the same X class name of XTerm). It was hard to put my finger on what was different -- the shape of all the letters looked the same, but it just seemed a little more ragged, and a little less compact, in xterm. I figured it was just a minor difference in their drawing code, or something.

Well, I was fiddling with fonts (trying to get the new-to-me "Inconsolata" font working) and I noticed that iso10646 bit. I didn't know what 10646 was, but shouldn't it be 8859-1 or 8859-15, the codes for the Latin-1 alphabet? After finishing up my Inconsolata experiments, when I set the font back to Vera I changed the line to XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso8859-15 and moved on to other things.

Until the next morning, when I booted up to a surprise: my main terminal window no longer fit on the screen. It seems it had reverted to the other (uglier) version of Vera Sans Mono, which is also very slightly taller, so instead of being a couple of lines shorter than the screen height, it was a couple of lines too tall to fit.

I checked .Xdefaults -- yes, it was still Vera. What was going on? I finally remembered the one thing I had changed: the language setting on the font, from 10646-1 to 8858-15. I changed it back: sure enough, now the font was pretty again and the terminal was short enough to fit.

I fired up xfontsel and did some experimenting. It turned out the difference between the two almost-identical Vera sans mono bold roman fonts is a field xfontsel calls "spc". It can be either 'c' or 'm'. The 'c' version is the pretty, compact font; the 'm' is the uglier, taller one. For some reason, specifying 10646-1 makes "spc" default to 'c', while 8859-15 makes it default to 'm'. But specifying 'c' in the font specifier gets the good version regardless of which language is specified.

So this would work: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-*-*

But then I read up on 10646-1 and it turns out to mean "the whole unicode character set". That sounds like a good idea, so I kept it in my font specifier after all: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-iso10646-1

(For the moment I still didn't know what spc, c or n meant; read on if you're curious.)

The second insight concerned a longstanding mystery of Dave's. He has been complaining for quite a while about the way Ubuntu's modern pango-based apps all refuse to see bitmapped fonts. (It bothered me too, but less so, because the terminal and editor apps I use can see X fonts.)

Dave has an Ubuntu install on one machine that he's been upgrading release after release, which does see his bitmapped fonts. But any fresh Ubuntu installation fails to see the fonts. What was the difference?

We knew about the trick of going into /etc/fonts/conf.d, removing the symbolic link 70-yes-bitmaps.conf and replacing it with a link to /etc/fonts/conf.avail/70-yes-bitmaps.conf ... But doing that doesn't actually change anything, and bitmap fonts still don't show up.

The secret turned out to be that you need to run fc-cache -fv after changing the font/conf.d links. This apparently never happens on its own -- not on a reboot, not on installing or uninstalling font packages. Somehow it had happened once on Dave's good install, and that's why it worked there but nowhere else.

I'm not sure how anyone is supposed to find out about fc-cache -- there's no man fontconfig, and the /etc/fonts/conf.avail/README offers no clue, just misleadingly says "Fontconfig scans this directory". man fc-cache mentions /usr/share/doc/fontconfig/fontconfig-user.html, which doesn't exist; it turns out on Ubuntu it's actually /usr/share/doc/fontconfig-config/fontconfig-user.html. But wait, that's just an html-ized manual page for fonts-conf, so actually you could just run man fonts-conf ... your guess is as good as mine why the fc-cache man page sends you on a hunt for html files instead.

man fonts-conf is good reading -- it even solves the mystery of that spc parameter. It stands for spacing and can be proportional, dual-width, monospace or charcell. Aha! And there's lots more useful-looking information in that manual page as well.

Tags: linux, fonts, i18n
[ 14:58 May 02, 2008    More linux | link to this entry ]

How often does updatedb really need to run?

Since updating to Hardy, I've been getting mail from Anacron:

/etc/cron.weekly/slocate:
slocate: fatal error: load_file: Could not open file: /etc/updatedb.conf: No such file or directory

That's the script that updates the database for locate, Linux's fast find system. I figured I must have screwed something up when I moved that slocate cron script from cron.daily to cron.weekly (because I hate having my machine slow to a crawl as soon as I boot it in the morning, and it doesn't bother me if the database doesn't necessarily have files added in the last day or two).

But after talking to some other folks and googling for Ubuntu bugs, I discovered I wasn't the only one getting that mail, and there was already a bug covering it. Comparing my setup with another Hardy user's, I found that the file slocate was failing to find, /etc/updatedb.conf, belongs to a different package, mlocate. If mlocate is installed, then slocate's cron script works; otherwise, it doesn't. Sounds like slocate should have a dependency that pulls in mlocate, no?

But wait, what do these two packages do? Let's try a little aptitude search locate:

p   dlocate                         - fast alternative to dpkg -L and dpkg -S   
p   kio-locate                      - kio-slave for the locate command          
i   locate                          - maintain and query an index of a directory
p   mlocate                         - quickly find files on the filesystem based
i   slocate                         - Secure replacement of findutil's locate   

Okay, forget the first two, but we have locate, mlocate, and slocate. How do they relate?

Worse, if I install mlocate (so slocate will work) and then look in my cron directories, it turns out I now have, count 'em, five different cron scripts that run updatedb. They are:

In cron.daily:

locate: 72 lines! but a lot of that is comments and pruning, and a lot of fiddling to figure out what version of the kernel is running to see whether it can pass any advanced flags when it tries to renice the process. In the end it calls updatedb.findutils (note no full path, though it uses a full path when it checks for it earlier in the script).

slocate: A much simpler but unfortunately buggy 20 lines. It checks for /etc/updatedb.conf, runs it if it exists, fiddles with ionice, checks again for /etc/updatedb.conf, and based on whether it finds it, runs either /usr/bin/slocate -u or /usr/bin/slocate -u -f proc. The latter path is what was failing and sending root mail every time the script was run.

mlocate: an even slimmer 12 line script, which checks for /usr/bin/updatedb.mlocate and, if it exists, fiddles ionice then runs /usr/bin/updatedb.mlocate.

In cron.weekly:

Two virtually identical scripts called find.notslocate and find.notslocate.dpkg-new, which differ only in dpkg-new having more elaborate ionice options. They both run updatedb. And which updatedb would that be? Probably /usr/bin/updatedb, which links to /etc/alternatives/updatedb, which probably links to either updatedb.mlocate or updatedb.slocate, whichever you've installed most recently. But in either case, it's hard to see why you'd need this script running weekly if you're already running both flavors of updatedb from other scripts cron.daily. And having two copies of the script is just plain wrong (and there was already a bug filed on it). (As long as you're poking around in cron.daily and cron.weekly, check and see if you have any more of these extra dpkg-new or dpkg-old scripts -- they might be slowing down your machine for no reason.)

Further research reveals that mlocate is a new(ish) package intended to replace slocate. (There was a long discussion of that on ubuntu-devel, leading to the replacement of slocate with mlocate very late in the Hardy development cycle. There was also lots of discussion of "tracker", apparently a GUI fast find tool that can only search in the user's home directory.)

What is this mlocate? The m stands for "merge": the advantage of mlocate is that it can merge new results into its existing database instead of replacing the whole thing every time. Sounds good, right? However, the down side is that mlocate apparently can't to purge its database of old files that no longer exist, and these files will clutter up your locate results. Running locate -e will keep them from being printed -- but there seems to be no way to set this permanently, via an environment variable or .locaterc file, nor to tell updatedb.mlocate to clean up its database. So you'll need to alias locate to locate -e if you want sensible behavior. Or go back to slocate. Sigh.

Cleaning up

The important thing is to get rid of most of those spurious updatedb cron scripts. You might choose to run updatedb daily, weekly, or only when you choose to run it; but you probably don't want five different scripts running two different versions of updatedb at different times. The packages obviously aren't cleaning up after themselves, so let's do a little manual cleanup.

That find.slocate script looks suspicious. In fact, if you run dpkg -S find.notslocate, you find out that it doesn't belong to any package -- not only should the .dpkg-old version not be there, neither should the other one! So out they go.

As for slocate and mlocate, it's important to know that the two packages can coexist: installing mlocate doesn't remove slocate or vice versa. A clean Hardy install should have only mlocate; upgrades from Gutsy are more likely to have a broken slocate.

Having both packages probably isn't what you want. So pick one, and remove or disable the other. If mlocate is what you want, apt-get purge slocate and just make sure that /etc/cron.*/slocate disappears. If you decide you want slocate, it's a little trickier since the slocate package is broken; but you can fix it by creating an empty /etc/updatedb.conf so updatedb.slocate won't fail.

Tags: linux, boot, ubuntu, install
[ 20:48 Apr 29, 2008    More linux/install | link to this entry ]

Republicans fight to preserve gender pay gap

Dahlia Lithwick wrote a terrific article in yesterday's Slate about the shameful behavior of the Republicans in the Senate in blocking a bill that would have allowed women to sue for pay discrimination.

The Lilly Ledbetter Fair Pay Act was written in response to the case brought by Lilly Ledbetter against the Goodyear Tire and Rubber Company. Courts had found that she was definitely the subject of discrimination: her pay was as much as 40% less than men doing a similar job (despite her excellent reviews), one year she was actually paid below Goodyear's own minimum threshold for that position, she had been explicitly barred from discussing salary with her coworkers (this is apparently legal, at least in Alabama), and she had been told explicitly by a manager at Goodyear that that the "plant did not need women, that [women] didn't help it, [and] caused problems."

No one at any level has disputed that Ms. Ledbetter was discriminated against -- even the Supreme Court. However, the Supremes threw out her appeal last year on the basis that the statute of limitations had run out and she should have filed her case within 180 days of receiving her first paycheck. In other words, as long as you don't know when you're hired that your pay is discriminatory, it doesn't matter if you find out later; it'll be too late then, so forget it. Pay discrimination is fine, and not actionable, as long as you can delay the victim's finding out about it for a few months.

Senate Republicans believe so strongly in a company's right to discriminate that they not only argued against the bill, they actually filibustered against it!

For more gory details of the case, read Lithwick's excellent Slate article. But even if you don't, be aware if you're considering voting for John McCain in November that although he was campaigning instead of voting on this bill, he proclaimed agreement with the rest of his party in opposing the Fair Pay Act.

So if you're against pay discrimination ... or if you're a woman and might be the victim of such discrimination ... be aware that John McCain is not on your side.

Tags: politics, chix, election08
[ 19:26 Apr 26, 2008    More politics | link to this entry ]

Autologin changes again for Hardy's upstart

Seems like each new Ubuntu release makes a few gratuitous changes to the syntax of system files. Today's change involves autologin, controlled by the "upstart" system (here's what I wrote about the previous syntax for autologin under upstart).

The /usr/bin/loginscript still hasn't changed, and this still works:

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

But the syntax has changed a little for the getty line in /etc/event.d/tty1: respawn is now on its own line (I don't know if that matters -- I still can't find any documentation on this file's syntax, though I found a new upstart page that links to some blog entries illustrating how upstart can be used to start system daemons like dbus). And the getty now needs an exec before it. Like this:

respawn
exec /sbin/getty -n -l /usr/bin/loginscript 38400 tty1

Tags: linux, ubuntu, boot
[ 14:27 Apr 22, 2008    More linux | link to this entry ]