Shallow Thoughts : : Jun
Akkana's Musings on Open Source Computing and Technology, Science, and Nature.
Wed, 30 Jun 2010
You read so much about the dire state of amphibians in today's world.
They're delicate -- they can absorb toxins through their porous skins,
making them prey to all the pollution the human world dumps at their
doorstep, as well as being prey for a wide assortment of larger animals
and prone to infection by parasites. I remember seeing lots of frogs
around ponds in the woods when I was growing up, and these days it's
rare to see a frog in the wild at all.
But sometimes you get lucky and get an indication that maybe the
state of amphibians isn't as dire as all that.
Mark Wagner gave me a tip (thanks, Mark!) that the pond at Picchetti
Ranch was literally hopping with frogs. I thought he must be
exaggerating -- but he wasn't.
They're tiny, thumbtip-sized creatures and they're everywhere around
the margin of the lake, hopping away as you approach. It's tough to get
photos because they move so fast and like to hide under grass stems,
but like anything else, take a lot of pictures and you'll get lucky
on a few.
The scene is absolutely amazing. If you're at all a frog fan in the
south bay area, get yourself to Picchetti and take a look -- but be
very, very careful where you step, because they're everywhere and
they're hard to spot between jumps.
I unfortunately lack a good amphibian field guide, and couldn't find
much on the web either, but some people seem to think these
Picchetti frogs are Sierran tree frogs -- which apparently are sometimes
are green, sometimes brown and have a wide range of markings, so
identifying them isn't straightforward.
Photos: Tiny frogs at
Piccheti Ranch.
Tags: nature, amphibian, frog, photo
[
19:14 Jun 30, 2010
More nature |
permalink to this entry |
]
Fri, 25 Jun 2010
Several groups I'm in insist on using LinkedIn for discussions,
instead of a mailing list. No idea why -- it's so much harder to use
-- but for some reason that's where the community went.
Which is fine except for happens just about every time I try to view
a discussion:
I get a notice of a thread that sounds interesting, click on the link
to view it, read the first posting, hit the space bar to scroll down
... whoops! Focus was in that silly search field at the top right of the page,
so it won't scroll.
It's even more fun if I've already scrolled down a bit with the
mousewheel -- in that case, hitting spacebar jumps back up to the
top of the page, losing any context I have as well as making me
click in the page before I can actually scroll.
Setting focus to search fields is a good thing on some pages.
Google does it, which makes terrific sense -- if you go to
google.com, your main purpose is to type something in that search box.
It doesn't, however, make sense on a page whose purpose is to
let people read through a long discussion thread.
Since I never use that search field anyway, though, I came up with
a solution using Firefox's user css.
It seems there's no way to make an input field un-focusable or
read-only using pure CSS (of course, you could use Javascript and
Greasemonkey for that); but as long as you don't need to use it,
you can make it disappear entirely.
Add this line to chrome/userContent.css inside your Firefox profile
(create it if it doesn't already exist):
form#global-search span#autocomplete-container input#main-search-box {
visibility:hidden;
}
Then restart Firefox and load a discussion page.
The search box should be hidden,
and spacebar should scroll the page just like it does on most web pages.
Of course, this will need to be updated the next time
LinkedIn changes their page layout. And it's vaguely possible that
somewhere else on the web is a page with that hierarchy of element names.
But that's easy enough to fix: run a View Page Source
on the LinkedIn page and add another level or two to the CSS rule.
The concept is the important thing.
Tags: html, web, css, tips, annoyances
[
17:17 Jun 25, 2010
More tech/web |
permalink to this entry |
]
Wed, 23 Jun 2010
My latest Linux Planet article came out a day early:
RAW
Support (and more) For Your Canon Camera With CHDK.
CHDK is a cool way you can load custom firmware onto a Canon camera.
It lets you do all sorts of useful hacks, from saving in RAW format
even in cameras that supposedly don't allow that, to getting more
control over aperture, shutter speed and other parameters, to
writing scripts to control the camera.
I didn't have space for all that in one article, so today's Part 1
simply covers how to install CHDK; Part 2, in two weeks, will
discuss some of the great things you can do with CHDK.
Tags: writing, photo
[
20:02 Jun 23, 2010
More photo |
permalink to this entry |
]
Tue, 22 Jun 2010
Another in the continuing series of
"This isn't documented anywhere and Google searches aren't helpful":
Dave's printer was failing to print on Ubuntu Lucid. The only
failure mode: pages came out with the single printed line,
Unable to open the initial device, quitting.
What a great, helpful error message! Thanks, CUPS!
Web searching found lots of people using HP printers, using various
versions of the HPLIP software to installer newer drivers and
otherwise reconfigure their HP setups.
Only problem: this printer isn't an HP. It's a Brother HL2070N,
which has given very good service and, until now, worked flawlessly
with every OS we've tried including Linux.
The solution? It turns out the problem really is HPLIP -- even if
the printer isn't an HP. What this message really meant was:
HPLIP isn't installed, and Ubuntu's CUPS refuses to work without it.
apt-get install hplip hplip-data
got the printer
working again.
Wouldn't it be nice if CUPS bothered to print error messages that
gave some hint of the real problem? Ideally, visible on the computer
to the user,
rather than on the printed page, so you don't have to waste 25 pages
of dead tree while you try to narrow down the problem?
Update: After further testing, we have established that a standard
Gnome-based Ubuntu Lucid machine needs hplip and hplip-data installed,
while a Lucid machine without Gnome needs those two plus hpijs. Or you
can get around needing any of them by ignoring CUPS' recommendation
for which driver to use, and choosing the Gutenprint driver in the
CUPS configuration screens.
A reader asked me if we had checked the CUPS error log. On one
machine, the log file was virtually empty; on another, there
actually were some lines about hpijs (nothing about hplip),
intermixed with a lot of debug chatter and a large number of errors
that were fairly clearly unrelated to anything we were doing.
Tags: linux, printing, cups
[
22:46 Jun 22, 2010
More linux |
permalink to this entry |
]
Sun, 20 Jun 2010
Regular readers probably know that I use
HTML
for the slides in my talks, and I present them either with Firefox
in fullscreen mode, or with my own Python
preso
tool based on webkit.
Most of the time it works great. But there's one situation that's
always been hard to deal with: low-resolution projectors.
Most modern projectors are 1024x768, and have been for quite a few years,
so that's how I set up my slides. And then I get asked to give a talk
at a school, or local astronomy club, or some other group that
has a 10-year-old projector that can only handle 800x600. Of course,
you never find out about this ahead of time, only when you plug in
right before the talk. Disaster!
Wait -- before you object that HTML pages shouldn't use pixel values and
should work regardless of the user's browser window size: I completely
agree with you. I don't specify absolute font sizes or absolute
positioning on web pages -- no one should.
But presentation slides are different: they're designed for
a controlled environment where everyone sees the same thing using the
same software and hardware.
I can maintain a separate stylesheet -- that works for making the
font size smaller but it doesn't address the problem of pictures too
large to fit (and we all like to use lots of pictures in presentations,
right?) I can maintain two separate copies of the slides for the two sizes,
but that's a lot of extra work and they're bound to get out of sync.
Here's a solution I should have thought of years ago: full-page zoom.
Most major browsers have offered that capability for years, so the
only trick is figuring out how to specify it in the slides.
IE and the Webkit browsers (Safari, Konqueror, etc.) offer a wonderful
CSS property called zoom. It works like this:
body {
zoom: 78.125%;
}
78.125% is the ratio between an 800-pixel projector and a 1024-pixel one.
Just add this line, and your whole page will be scaled down to the
right size. Lovely!
Lovely, except it doesn't work on Firefox
(bug 390936).
Fortunately, Firefox has another solution: the more general and not yet
standardized CSS transform, which Mozilla has implemented as the
Mozilla-specific property
-moz-transform.
So add these lines:
body {
position: absolute; left: 0px; top: 0px;
-moz-transform: scale(.78125, .78125);
}
The position: absolute is needed because when Firefox scales
with -moz-transform, it also centers whatever it scaled, so the
slide ends up in the top center of the screen.
On my laptop, at least, it's the upper left part of the screen that
gets sent to the projector, so slides must start in the upper left corner.
The good news is that these directives don't conflict; you can put
both zoom and -moz-transform in the same rule and things
will work fine. So I've added this to the body rule in my slides.css:
/* If you get stuck on an 800x600 projector, use these:
zoom: 78.125%;
position: absolute; left: 0px; top: 0px;
-moz-transform: scale(.78125, .78125);
*/
Uncomment in case of emergency and all will be well.
(Unless you use Opera, which doesn't seem to understand either version.)
Tags: speaking, html, css, browsers, firefox, mozilla
[
12:14 Jun 20, 2010
More tech/web |
permalink to this entry |
]
Fri, 18 Jun 2010
While I was in Europe, Dave stumbled on a handy alias on his Mac to
check the time where I was:
date -v +10
(+10 is the offset
from the current time). But when he tried to translate this to Linux,
he found that the -v flag from FreeBSD's
date
program
wasn't available on the GNU
date
on Linux.
But I suggested he could do the same thing with the TZ environment variable.
It's not documented well anywhere I could find, but if you set TZ to
the name of a time zone, date
will print out the time for
that zone rather than your current one.
So, for bash:
$ TZ=Europe/Paris date # time in Paris
$ TZ=GB date # time in Great Britain
$ TZ=GMT-02 date # time two timezones east of GMT
or for csh:
% ( setenv TZ Europe/Paris; date)
% ( setenv TZ GB; date)
% ( setenv TZ GMT-02; date)
That's all very well. But when I tried
% ( setenv TZ UK; date)
% ( setenv TZ FR; date)
they gave the wrong time, even though Wikipedia's
list
of time zones seemed to indicate that those abbreviations were okay.
The trick seems to be that setting TZ only works for abbreviations
in /usr/share/zoneinfo/, or maybe in /usr/share/zoneinfo/posix/.
If you give an abbreviation, like UK or FR or America/San_Francisco,
it won't give you an error, it'll just print GMT as if that was what
you had asked for.
So this trick is useful for printing times abroad -- but if you want
to be safe, either stick to syntaxes like GMT-2, or make a script that
checks whether your abbreviation exists in the directory before
calling date, and warns you rather than just printing the wrong time.
Tags: linux, tips, travel, cmdline
[
14:04 Jun 18, 2010
More linux/cmdline |
permalink to this entry |
]
Sun, 13 Jun 2010
Update: though the rest of this article is still useful in
explaining how to un-blacklist the pcspkr module, unfortunately
that module works very erratically. Sometimes you'll get a beep,
sometimes not. So this article may be a good start but it still
doesn't explain why Ubuntu's kernels have such a flaky pcspkr module.
For years I've used Ubuntu with my own kernels rather than the kernels
Ubuntu provides. I have several reasons: home-built kernels boot a lot
faster (when I say a lot, I mean like saving 30 seconds off a one-minute
boot) and offer more control over options. But a minor reason is that
Ubuntu kernels generally don't support the system beep, so for example
there's no way to tell in vim when you get out of insert mode. (In the
past I've sometimes used the excellent
fancy beeper
module to play sounds, but I don't always want that.)
On Ubuntu's latest "Lucid Lynx", I'm using their kernel (so far).
The Ubuntu kernel team has made huge improvements in boot time and number
of modules loaded, so it's much more efficient than past kernels.
But it did leave me without a beeper.
modprobe pcspkr
failed to do anything except print the enigmatic:
WARNING: All config files need .conf: /etc/modprobe.d/00local, it will be ignored in a future release.
modprobe -v pcspkr
(verbose) was no help -- it printed
install /bin/true
which didn't make anything clearer.
To get my beep back, I had to do two things:
First, edit /etc/modprobe.d/blacklist.conf and comment out the line
blacklisting pcspeakr. It looks like this:
# ugly and loud noise, getting on everyone's nerves; this should be done by a
# nice pulseaudio bing (Ubuntu: #77010)
blacklist pcspkr
(They don't seem to be concerned about anyone who doesn't run Pulse,
or about the various other bugs involved -- there's quite a laundry
list in
bug
486154.)
Secomd. pcspkr was blacklisted a second time in a different way, in that
file so confusingly alluded to by the warning. /etc/modprobe.d/00local
was apparently left over from a previous version of Ubuntu, and never
removed by any upgrade script, and consisted of this:
install pcspkr /bin/true
Aha! So that's why modprobe -v pcspkr
printed
install /bin/true
-- because that's all it was doing instead
of loading the module like I'd asked.
So rm /etc/modprobe.d/00local
was the second step, and
once I'd done that, modprobe pcspkr
loaded the module and
gave me my system beep.
Tags: ubuntu, lucid, audio
[
14:02 Jun 13, 2010
More linux/kernel |
permalink to this entry |
]
Thu, 10 Jun 2010
I'm back from Europe (and still recovering from a cold picked up
right after I got back).
And today I have a GIMP quickie on Linux Planet discussing three ways
to add three-dimensional looks to otherwise flat images in GIMP:
GIMP
3-D, 3 Ways.
Tags: writing, gimp
[
10:36 Jun 10, 2010
More gimp |
permalink to this entry |
]