Shallow Thoughts : : Mar

LCD Burn-In, er, "Image Persistence"

Mostly, I love my Dell 2005FPW S_IPS monitor. Nice colors, sharp image, incredibly w ide viewing angles. But one thing made me uneasy: while working on a smooth gradient in GIMP, I noticed some funky pixels in the bottom right of the screen, where I could see horizontal bars where the image clearly didn't have them. And if I moved the image, the bars stayed put. Oh no! My lovely monitor maybe wasn't so lovely!

Since then I've been pretending not to notice (I bought the monitor used, so warranty return isn't an option). But yesterday, I maximized Firefox on a page with a medium cyan background -- and that barred area was a lot worse.

In fact, it was so much worse that I could see detail in it: it was my xchat window. I could even read some of the menubar items.

It's an LCD! They don't get burn-in ... do they?

Well, yes, it turns out, they do. Only it's not called "burn-in", it's called "image persistence". And for some people, it happens very quickly, while other people never see it. Anecdotally S-IPS monitors seem to show image persistence a lot more easily than TN monitors, but nobody seems to know why.

The good news is that it's temporary -- it's not permanent burn-in like old CRTs sometimes showed. The solutions most people suggest:

• turn off the monitor for a time comparable to the time the image has been burning in
• display a constantly changing screensaver for a long time (hours or days)
• display all white for a long time

On my monitor, about an hour and a half of all-white made it better, and after turning it off overnight, the next morning I could no longer see any trace of the persistent image.

So I guess I need to change my habits. I already use power saving mode so the screen sleeps when I'm not there (no screensaver); but on the other hand I'm at the machine day and night, and I like to keep windows in the same place.

• No more windows visible on all desktops
• Try to put windows in different places on each virtual desktop, and move them around some
• Periodically invert the screen colors

How do you invert the screen? You'd think there would be a gazillion programs to do that on X, but there aren't. You can compile a C program called sgamma then run sgamma -b -1 to invert, and sgamma -b 1 to restore. It restores to full brightness, though, so if you've changed your brightness using a program like xbrightness you'll have to adjust it again afterward. Alternately, Guillermo showed me a nice little C program called invgamma, by Ben Winslow, that just inverts whatever gamma curve you already have (run it again to undo the effects). Ben doesn't seem to have a page for it and it doesn't have any license info in it so I can't put it on my site either, but if you google for it you'll probably find a copy.

I'm a trifle bummed that the whizzy S-IPS monitor turned out to be so delicate. But I suppose it's good to change habits now and then anyway and not get too stuck on particular window positions. Maybe it'll help keep my brain from burn-in too.

References:

• A blog write-up on LCD screen burn
• Wikipedia: Image persistence
• About.com: LCD Burn-in

Tags: LCD, monitor, S-IPS, burn-in, image persistence
[ 12:21 Mar 28, 2009    More tech | permalink to this entry | ]

Emacs bookmarks -- a huge time-saver

Oh, wow. I can't believe I've used Emacs all these years without knowing about bookmarks.

I wanted something in Emacs akin to the "Open Recent" menu that a lot of GUI apps have. Except, well, I didn't want it to need a menu (I don't normally show a menubar in Emacs) and I didn't want it limited only to recently accessed files. So ... just like Open Recent, only completely different.

What I really wanted was a way to nickname files I access regularly, so I don't have to type ~/foo/bar/blaz/route-66/dufus/velociraptor/archaeopteryx/filename every time. Even with tab completion, remembering long paths gets old. Of course emacs must have a way to do that; it has everything. The trick was guessing what it might be called in order to search for it.

The answer is emacs bookmarks and they're super easy to use.

C-x r m sets a bookmark for the current location in the current file. It prompts for a bookmark name; give it a nickname, or hit return to default it to the current filename.

C-x r b bookmark-name jumps back to a bookmark, opening the file if it isn't already. Of course, tab completion works for the bookmark name.

Bookmarks are saved in ~/.emacs.bmk so they're persistent.

It's perfect. I just wish I'd thought to look for it years ago.

(Of course, Emacs can do recent files too.)

Tags: editors, emacs, bookmarks
[ 10:21 Mar 27, 2009    More linux/editors | permalink to this entry | ]

GUI Programming in Python For Beginners

Latest on Linux Planet: another introductory programming article, this time on Python's tkinter library: GUI Programming in Python For Beginners. (As usual, there's a Digg link and also a Reddit one.)

Tags: writing, python, programming
[ 16:36 Mar 26, 2009    More writing | permalink to this entry | ]

For Ada Lovelace Day: Vera Rubin

For Ada Lovelace Day I'm honoring Vera Rubin.

In 1948, when she applied to Princeton as an aspiring astronomy grad student, they wouldn't let her in because women weren't allowed. (They finally started admitting women in 1975.) Fortunately, Cornell was more accommodating.

For her thesis, she worked on a project that seemed useful and uncontroversial. She took other people's data on the redshifts of galaxies, and catalogued them to see how fast they were all moving away from us.

Except something unexpected happened. She found that galaxies in one direction weren't moving away as fast as galaxies in the other directions. The universe was supposed to be expanding evenly in all directions -- but that's not what her data showed.

In 1950 she presented her results to a conference of the American Astronomical Society. The results were not promising. Famous astronomers she'd read about but never met stood up in the audience to ridicule her paper and say it couldn't be true. No one would publish her master's thesis. It wasn't a good start to her career. She decided to try to find something less controversial to study.

Her husband finished at Cornell and moved to Washington, D.C.. Rubin and her new baby moved with him, and she enrolled as a PhD student at Georgetown. They had two children by now; her parents watched the kids while she took night classes.

She hooked up with George Gamow at Georgetown. He called her to ask her about her research -- but said they'd have to talk in the lobby, not in his office, because women weren't allowed in the office area of the building.

After Rubin finished her PhD with Gamow in 1954, Her experience trying to present her 1950 paper made her leery of confrontation. She's said, "I wanted a problem that no one would bother me about." Working with Kent Ford at the Carnegie Institute in Washington, she helped design a super-sensitive digital spectrograph, and they set out to make a huge catalog of data on boring "normal" galaxies no one else was looking at. They started with the Andromeda galaxy, M31, the closest large galaxy to us (and the easiest one to see with the naked eye, if you go somewhere away from city lights).

And right away they found something weird. Normally, you'd expect the outer parts of the galaxy to be rotating a lot slower than the inner parts. Think of our solar system: Mercury goes around the sun really fast (a Mercury year is only 88 days), Earth goes not quite as fast, and when you get all the way out to Pluto, it takes 247 years to go around the sun once. It's not just that it has farther to go to make a circuit around the sun; it's that the sun's influence is so weak way out there that Pluto goes a lot slower in its orbit than we do.

Galaxies should be the same way: stars in the center should just whiz around in no time, while stars at the outer edge take forever.

But Rubin and Ford found that Andromeda wasn't like that. When they started looking at the stars farther out, they were all going about the same speed. If anything, the stars at the edge were going a little faster than the stars in the center.

That made no sense. It didn't follow any normal model of gravity or galaxy formation. They published their results in 1970, but no one took them seriously. They decided that maybe something was wrong, or their equipment was faulty. They decided to try studying a simpler problem: just measure the redshift of some faint galaxies and make a catalog of those.

That went well for a while -- except that pretty soon, they ran into the same thing Rubin had discovered as a graduate student back at Cornell. Galaxies in the direction of Pegasus were moving away from us at a different speed from galaxies in other parts of the sky. She and Ford tried again to present that, but the reaction wasn't any more positive this time.

Discouraged, they went back to trying to measure galaxy rotation, hoping Andromeda had just been a fluke. But every galaxy they studied looked the same as Andromeda, with the stars far out near the edge of the galaxy rotating as fast, or faster, than the stars near the hub.

There were only two possible explanations. Either the law of gravity doesn't work the way we think it does ... or there's a lot more matter inside a galaxy than what we see with a telescope.

When they tried to present this result, no one believed it, so they kept measuring more galaxies, always with the same result.

By 1985, they had enough evidence that people finally started paying attention. As their results got talked about more and taken more seriously, they came up with a name for the extra mass that makes the galaxy rotation flat: "dark matter". Yes, the dark matter you hear about that apparently makes up more than 90% of all matter in the universe. Not a bad discovery for someone who was just trying to lay low and catalogue a lot of data that might be useful to other people! (Rubin's first graduate project, on the rotation of the universe, has also since been vindicated.)

Vera Rubin is still working at the Department of Terrestrial Magnetism. Her intellect, hard work and perseverance are an inspiration, and I salute her on Ada Lovelace Day. (You can read other people's Ada Lovelace Day posts in the Ada Lovelace Day Collection.)

Tags: AdaLovelaceDay09, chix, astronomy
[ 20:12 Mar 24, 2009    More science/astro | permalink to this entry | ]

Vim tip: fixing the light-background color schemes

I use a light background for my X terminals (xterm and rxvt): not white, but a light grey that I find easy on the eyes. Long ago, I spent the time to set up a custom vim color scheme that works with the light background.

But sometimes I need to run vim somewhere where I don't have access to my custom scheme. It always starts up with a lot of the words displayed in yellow, completely unreadable against a light background. :set background=light doesn't help -- the default colorscheme is already intended for a light background, yet it still uses yellow characters.

I tried all the colorschemes installed with ubuntu's vim (you can get a list of them with ls /usr/share/vim/vim71/colors). The only light-background vim schemes that don't use yellow all have their primary text color as red. Do a lot of people really want to edit red text? Maybe the same people who think that yellow is a dark color?

Curiously, it turns out that if you use one of these light color schemes on a Linux console (with its black background), the yellow text isn't yellow (which would show up fine against black), but orange (which would be better on a light background).

Mikael knew the answer:

:set t_Co=88

This tells vim to use 88-color mode instead of its default of 8, and the yellow text turns light blue. Not terrifically readable but much better than yellow. Or, instead, try

:set t_Co=256

and the yellow/light blue text turns an ugly, but readable, orange (probably the same orange as the console used).

So, vim users with dark-on-light terminal schemes: add set t_Co=256 in your .vimrc (no colon) and you'll be much happier.

Update: Pádraig Brady has a great page explaining more about terminal colour highlights, including a TERM=xterm-256color setting to get vim to use 256 colors automatically. There's also a lot of good advice there on enabling colors in other console apps.

The only catch: on Ubuntu you do have to install the ncurses-term package, which will get you xterm-256color as well as 256color variants for lots of other terminal types. Here's useful page on 256-Color XTerms in Ubuntu.

Tags: editors, vim, color, tips
[ 22:29 Mar 22, 2009    More linux/editors | permalink to this entry | ]

Quick tip: When Firefox forgets bookmarks

Firefox started forgetting new bookmarks. I'd make a few bookmarks, filing them in the right place ... then the next time I started up, they wouldn't be there and I had to go find them again. I tested and verified that it wasn't that I was exiting Firefox uncleanly; even if I ran from the terminal, made a bookmark, and exited, nothing would be saved.

It took me forever to find anything on this with google, so I'm blogging it in the hope of making it easier for the next person to find. It turns out the Mozilla Knowledge Base has a terrific article called Bookmarks not saved that discusses lots of ways this can happen. Go through the list and you'll probably find a solution.

In my case it was the second item: "Places preferences - Firefox 3". It turned out that all three of my boolean browser.places preferences were set to non-default values -- not by me, since I'd never heard of any of the browser.places preferences before. After toggling all three of them by double-clicking, Firefox lost its anterograde amnesia and started remembering new bookmarks again.

Tags: firefox, mozilla, tips
[ 23:01 Mar 18, 2009    More tech/web | permalink to this entry | ]

The new gtk file selector fstab viewer

When I upgraded to Ubuntu Intrepid recently, I pulled in a newer GTK+, version 2.14.4. And when I went to open a file in GIMP, I got a surprise: my "bookmarks" were no longer visible without scrolling down.

In the place where the bookmarks used to be, instead was a list of ... what are those things? Oh, I see ... they're all the filesystems listed with "noauto" in my /etc/fstab --the filesystems that aren't mounted unless somebody asks for them, typically by plugging in some piece of hardware.

There are a lot of these. Of course there's one for the CDROM drive (I never use floppies so at some point I dropped that entry). I have another entry for Windows-formatted partitions that show up on USB, like when I plug in a digital camera or a thumb drive. I also have one of those front panel flash card readers with 4 slots, for reading SD cards, memory sticks, compact flash, smart media etc. Each of those shows up as a different device, so I treat them separately and mount SD cards as /sdcard, memory sticks as /stick and so on. In addition, there are entries corresponding to other operating systems installed on this multi-boot machine, and to several different partitions on my external USB backup drive. These are all listed in /etc/fstab with entries like this:

/dev/hdd   /cdrom  udf,iso9660  user,noauto               0  0
/dev/sde1  /pix    vfat         rw,user,fmask=133,noauto  0  0

The GTK developers, in their wisdom, have realized that what the file selector really needs to be. I mean, I was just thinking while opening a file in GIMP the other day,

"Browsing image files on filesystems that are actually mounted is so tedious. I wish I could do something else instead, like view my /etc/fstab file to see a list of unmounted filesystems for which I might decide to plug in an external device."

Clicking on one of the unmounted filesystems (even right-clicking!) gives an error:

Could not mount sdcard
mount: special device /dev/sdb1 does not exist

So I guess the intent is that I'll plug in my external drive or camera, then use the gtk file selector from a program like GIMP as the means to mount it. Um ... don't most people already have some way of mounting new filesystems, whether it's an automatic mount from HAL or typing mount in a terminal?

(And before you ask, yes, for the time being I have dbus and hal and fam and gamin and all that crap running.)

The best part

But I haven't even told you the best part yet. Here it is:

If you mount a filesystem manually, e.g. mount /dev/sdb1 /mnt ... it doesn't show up in the list!

So this enormous list of filesystems that's keeping me from seeing my file selector bookmarks ... doesn't even include filesystems that are really there!

Tags: gtk, user interface, humor, linux
[ 12:59 Mar 14, 2009    More linux | permalink to this entry | ]

Linux Planet: Basic Shell Scripting

I'm beginning a programming series on Linux Planet, starting with a basic intro to shell scripting for people with no programming experience: Intro to Shell Programming: Writing a Simple Web Gallery

(For those inclined, digg and reddit links).

Tags: writing, shell, CLI
[ 23:08 Mar 12, 2009    More writing | permalink to this entry | ]

Upgraded to Intrepid: X keyboard options and losing network after suspend

I finally got around to upgrading to the current Ubuntu, Intrepid Ibex. I know Intrepid has been out for months and Jaunty is just around the corner; but I was busy with the run-up to a couple of important conferences when Intrepid came out, and couldn't risk an upgrade. Better late than never, right?

The upgrade went smoothly, though with the usual amount of babysitting, watching messages scroll by for a couple of hours so that I could answer the questions that popped up every five or ten minutes. Question: Why, after all these years of software installs, hasn't anyone come up with a way to ask all the questions at the beginning, or at the end, so the user can go have dinner or watch a movie or sleep or do anything besides sit there for hours watching messages scroll by?

XKbOptions: getting Ctrl/Capslock back

The upgrade finished, I rebooted, everything seemed to work ... except my capslock key wasn't doing ctrl as it should. I checked /etc/X11/xorg.conf, where that's set ... and found the whole file commented out, preceded by the comment:

# commented out by update-manager, HAL is now used

Oh, great. And thanks for the tip on where to look to get my settings back. HAL, that really narrows it down.

Google led me to a forum thread on Intrepid xorg.conf - input section. The official recommendation is to run sudo dpkg-reconfigure console-setup ... but of course it doesn't allow for options like ctrl/capslock. (It does let you specify which key will act as the Compose key, which is thoughtful.)

Fortunately, the release notes give the crucial file name: /etc/default/console-setup. The XKBOPTIONS= line in that file is what I needed.

It also had the useful XKBOPTIONS="compose:menu" option left over from my dpkg-configure run. I hadn't known about that before; I'd been using xmodmap to set my multi key. So my XKBOPTIONS now looks like: "ctrl:nocaps,compose:menu".

Fixing the network after resume from suspend

Another problem I hit was suspending on my desktop machine. It still suspended, but after resuming, there was no network. The problem turned out to lie in /etc/acpi/suspend.d/55-down-interfaces.sh. It makes a list of interfaces which should be brought up and down like this:

IFDOWN_INTERFACES="`cat /etc/network/run/ifstate | sed 's/=.*//'`"
IFUP_INTERFACES="`cat /etc/network/run/ifstate`"

However, there is no file /etc/network/run/ifstate, so this always fails and so /etc/acpi/resume.d/62-ifup.sh fails to bring up the network.

Google to the rescue again. The bad thing about Ubuntu is that they change random stuff so things break from release to release. The good thing about Ubuntu is a zillion other people run it too, so whatever problem you find, someone has already written about. Turns out ifstate is actually in /var/run/network/ifstate now, so making that change in /etc/acpi/suspend.d/55-down-interfaces.sh fixes suspend/resume. It's bug 295544, fixed in Jaunty and nominated for Intrepid (I just learned about the "Nominate for release" button, which I'd completely missed in the past -- very useful!) Should be interesting to see if the fix gets pushed to Intrepid, since networking after resume is completely broken without it.

Otherwise, it was a very clean upgrade -- and now I can build the GIMP trunk again, which was really the point of the exercise.

Tags: ubuntu, linux, install, X11, networking
[ 18:28 Mar 11, 2009    More linux/install | permalink to this entry | ]

Classic cellphone billboard

On 101 southbound a little south of University Ave in Palo Alto, a new billboard cropped up a month or so ago. It says:

Senator Joe Simitian: Your cell phone law sucks.

Well, that's not ALL it says. Actually, it says quite a lot of other stuff. In small print. So much so that if you actually tried to read it, you'd be virtually guaranteed to veer out of your lane and into another car.

I loved it. It's so classic. For anyone who hasn't heard, California has a new law this year that bans talking on a hand-held cell phone while driving. And honestly, who would think that it was possible to read a billboard like this while driving -- except one of those people who veers their SUV into your lane because they're too immersed in their cellphone conversation to pay attention to the road?

(For a better photo or if you actually want to read the text, the LA Times has the billboard story and photo; here's the Mercury news take, with more details on the 75-word message (no photo).)

Tags: humor, irony, cellphone
[ 21:53 Mar 10, 2009    More humor | permalink to this entry | ]

Quickie tutorial: Making an encrypted USB key or SD card

USB flash drives and SD cards are getting so big -- you can really carry a lot of stuff around on them. Like a backup of your mail directory, your dot files, your website, stuff you'd really rather not lose. You can even slip an SD card into your wallet.

But that convenient small size also means it's easy to lose your USB key, or leave it somewhere. Someone could pick it up and have access to anything you put there. Wouldn't it be nice to encrypt it?

There are lots of howtos on the net, like this and this, but most of them are out of date and need a bit of fiddling to get working. So here's one that works on Ubuntu hardy and a 2.6.28 kernel. I'll assume that the drive is on /dev/sdb.

First, consider making two partitions on the flash drive. The first partition is a normal unencrypted vfat partition, so you can use it to transfer files to other machines, even Windows and Mac. The second partition will be your encrypted file system. Use fdisk, gparted or your favorite partitioning tool to make the partitions, then create a filesystem on the first:

mkfs.vfat /dev/sdb1

Update: On many distros you'll probably need to load the "cryptoloop" module before proceeding with the following steps. Mount it like this (as root):

modprobe cyptoloop

Easy, moderate security version

Now create the encrypted partition (you'll need to be root). I'll start with a relatively low security version -- good enough to keep out most casual snoops who happen to pick up your flash drive.

losetup -e aes /dev/loop0 /dev/sdb2
[type a password or pass phrase]
mkfs.ext2 /dev/loop0
losetup -d /dev/loop0

I used ext2 as the filesystem type. I want a Linux filesystem, not a Windows one, so I can store dot-filenames like .gnupg/ and so I can make symbolic links. I chose ext2 rather than a journalled filesystem like ext3 because of kernel configuration warnings: to get encrypted mounts working I had to enable loopback and cryptoloop support under drivers/block devices, and the cryptoloop help says:

WARNING: This device is not safe for journaled file systems like ext3 or Reiserfs. Please use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device.

I hunted around a bit for this "device mapper crypto module" and couldn't figure out where or what it was (I wish kernel help files would give either the path to the option, or the CONFIG_ name in .config!) so I decided I'd better stick with non-journalled filesystems for the time being.

Now the filesystem is ready to use. Mount it with:

mount -o loop,encryption=aes /dev/sdb2 /mnt
[type your password/phrase]

Higher security version

There are several ways you can increase security. Of course, you can choose other encryption algorithms than aes -- that choice is up to you.

You can also use a random key, rather than a password you type in. Save the random key to a file on your system (obviously, you'll want to back that up somewhere else). This has both advantages and disadvantages: anyone who has access to your computer has the key and can read your encrypted disk, but on the other hand, someone who finds your flash drive somewhere will be very, very unlikely to be able to use it. Set up a random key like this:

dd if=/dev/random > /etc/loop.key bs=1 count=60
mkfs.ext2 /dev/loop0
losetup -e aes -p 0 /dev/loop0 /dev/sdb2 < /etc/loop.key

(of course, you can make it quite a bit longer than 60 bytes).

(Update: skipped mkfs.ext2 step originally.)

Then mount it with:

cat /etc/loop.key | mount -p0 -o loop,encryption=aes /dev/sdb2 /crypt

Finally, most file systems write predictable data, like superblock backups, at predictable places. This can make it easier for someone to break your encryption. In theory, you can foil this by specifying an offset so those locations are no longer so predictable. Add -o 123456 (of course, use your own offset, not that one) to the losetup line, and ,offset=123456 in the options of the mount command. In practice, though, offset doesn't work for me: I get

ioctl: LOOP_SET_STATUS: Invalid argument

whenever I try to specify an offset. I haven't pursued it; I'm not trying to hide state secrets, so I'm more worried about putting off casual snoops and data thieves.

Tags: linux, security, filesystems, backups
[ 15:10 Mar 08, 2009    More tech/security | permalink to this entry | ]

Categorize your fonts with fontypython

We were talking about fonts on #gimp-users and someone mentioned fontmatrix as a way to tag and organize fonts. (Tagging of resources like fonts is on ongoing GIMP project, and with any luck will be available in a future release.)

I tried fontmatrix and found it complex and inscrutable. But it made me look for smaller font-tagging projects, and that led me to FontyPython. It's fairly small, it's Python, it's already included in Ubuntu ... and how can you not like a project with a name like that?

When you start up, you need to choose a font folder to view any fonts. Unfortunately, the standard place to put fonts on a modern Linux system, ~/.fonts, is not an option: fontypython won't look in directories starting with a dot. The only way to view fonts installed in .fonts is to specify it on the command line: fontypython .fonts

I talked to the author, and it turns out the intent is quite different: you're intended to keep your font list somewhere else (say, ~/myfonts) and use fontypython to move fonts in and out of ~/.fonts, with the Install button. That model doesn't quite match my workflow -- I'd have to keep telling apps like GIMP to rescan the font list as I added and removed fonts (and other apps besides GIMP mostly need to be restarted to see new fonts) -- but it's probably ideal for some people.

When you first start up fontypython it displays the first page of your fonts. Instead of a scrollbar, you page through using the Back/Forward buttons or the option menu down below the font list. By default, fonts are displayed quite large; you can change the size in File->Settings if you want to see more at once.

It's time to start categorizing! To do that, you need to create some pogs, a silly term taken from tyPOGraphy. Pogs are just categories of font. Click on New Pog in the buttons at the bottom right of the window and choose a name for your first pog -- you might want pogs for "script", or "handwriting", or "gothic", or "outline".

Once you've created some pogs, select one in the Target list along the right edge of the window. That's your active pog. Add fonts to the pog by clicking on them in the list (a big red checkmark will appear over the font). Mark as many as you want to move, then click "Put fonts into pogname" at the bottom of the window. Those fonts will grey out, to indicate that they're members of the current pog.

To view fonts by pog -- to view all your handwriting or script fonts -- use the Pogs tab near the upper left of the window.

Nothing to it! Unfortunately, the python routines fontypython uses fails on a few fonts; but that's true of most font viewers (like gtkfontsel), and fontypython does better than many. It does offer a way to screen out bad fonts that can't display, in case you have any fonts that cause serious problems like crashes (I didn't).

Quite a useful program if you're a font junkie like I am! I'm looking forward to using it for real projects.

Tags: fonts, linux
[ 13:13 Mar 06, 2009    More linux | permalink to this entry | ]

Ellie: Plot GPS elevation profiles

Ever since I got the GPS I've been wanting something that plots the elevation data it stores. There are lots of apps that will show me the track I followed in latitude and longitude, but I couldn't find anything that would plot elevations.

But GPX (the XML-based format commonly used to upload track logs) is very straightforward -- you can look at the file and read the elevations right out of it. I knew it wouldn't be hard to write a script to plot them in Python; it just needed a few quiet hours. Sounded like just the ticket for a rainy day stuck at home with a sore throat.

Sure enough, it was fairly easy. I used xml.dom.minidom to parse the file (I'd already had some experience with it in gimplabels for converting gLabels templates), and pylab from matplotlib for doing the plotting. Easy and nice looking.

I even threw in the nice "conditional main" code from Matt Harrison's SCALE7x Python talk, so it should be callable from other Python code.

Here's the page and a screenshot: Ellie: plot elevation from a GPS track.

Tags: programming, mapping, python
[ 17:57 Mar 03, 2009    More programming | permalink to this entry | ]

Simple pinning

"Pinning" is the usual way Debian derivatives (like Ubuntu) deal with pulling software from multiple releases. For instance, you need an updated gtk or qt library in order to build some program, but you don't want to pull in everything else from the newer release.

But most people, upon trying to actually set up pinning, get lost in the elaborate documentation and end up deciding maybe they don't really need it after all.

For years, I've been avoiding needing to learn pinning because of a wonderful LinuxChix Techtalk posting from Hamster years ago on easier method of pinning releases Basically, you add a line like:

APT::Default-Release "hardy";

to your /etc/apt/apt.conf (creating it if it doesn't already exist). Then when you need to pull something from the newer repository you pull with apt-get install -t hardy-backports packagename.

That's generally worked for me, until yesterday when I tried to pull a -dev package and found out it was incompatible with the library package I already had installed. It turned out that the lib package came from hardy-security, which is considered a different archive from hardy, so my Default-Release didn't apply to security updates (or bugfixes, which come from hardy-updates).

You can apparently only have one Default-Release. Since Ubuntu uses three different archives for hardy the only way to handle it is pinning. Pinning is documented in the man page apt_preferences(5) -- which is a perfect example of a well intentioned geek-written Unix man page. There's tons of information there -- someone went to a lot of work, bless their heart, to document exactly what happens and why, down to the algorithms used to decide priorities -- but straightforward "type X to achieve effect Y" examples are lost in the noise. If you want to figure out how to actually set this up on your own system, expect to spend a long time going back and forward and back and forward in the man page correlating bits from different sections.

Ubuntu guru Mackenzie Morgan was nice enough to help me out, and with her help I got the problem fixed pretty quickly. Here's the quick recipe:

First, remove the Default-Release thing from apt.conf.

Next, create /etc/apt/preferences and put this in it:

Package: *
Pin: release a=hardy-security
Pin-Priority: 950

Package: *
Pin: release a=hardy-updates
Pin-Priority: 940

Package: *
Pin: release a=hardy
Pin-Priority: 900

# Pin backports negative so it'll never try to auto-upgrade
Package: *
Pin: release a=hardy-backports
Pin-Priority: -1

Here's what it means:

a= means archive, though it's apparently not really needed.

The hardy-security archive has the highest priority, 950. hardy-updates is right behind it with 940 (actually, setting these equal might be smarter but I'm not sure it matters).

hardy, which apparently is just the software initially installed, is lower priority so it won't override the other two.

Finally, hardy-backports has a negative priority so that apt will never try to upgrade automatically from it; it'll only grab things from there if I specify apt-get install -t hardy-backports.

You can put comments (with #) in /etc/apt/preferences but not in apt.conf -- they're a syntax error there (so don't bother trying to comment out that Default-Release line).

And while you're editing apt.conf, a useful thing to put there is:

APT::Install-Recommends "false";
APT::Install-Suggests "false";

which prevents apt from automatically installing recommended or suggested packages. Aptitude will still install the recommends and suggests; it's supposed to be configurable in aptitude as well, but turning it off never worked for me, so mostly I just stick to apt-get.

Tags: debian, ubuntu, pinning
[ 21:19 Mar 01, 2009    More linux/install | permalink to this entry | ]