Shallow Thoughts : : Nov

Debug logging in Javascript under Firefox

While debugging Javascript, I've occasionally come across references to a useful function called console.log. Supposedly you can log errors with a line like:

  console.log(""key press, char code " + e.charCode);

Since the only native way of logging debug statements in Javascript is with a pop-up alert() box, having a less obtrusive way to print is something any JS programmer could use.

The catch? It didn't do anything -- except print console is not defined.

Today a friend was crowing about how wonderful Javascript debugging was in Google's Chrome browser -- because it has functions like console.log.

After some searching and poking around, we determined that Firefox also has console.log -- it's just well hidden and a bit hard to get going.

First, you need the Firebug extension. If you're developing Javascript, you probably already have it. If not, you need it.

Run Firebug and click to the Console tab. Now click on the tiny arrow that shows up at the right edge of that tab, as shown. Turns out there's a whole menu of options under there -- one of which is Enabled.

But wait, that's not all. In my case, the console was already Enabled according to the menu. To get the console working, I had to

1. Disable the console
2. Re-enable it
3. Shift-reload the page being debugged

My friend also said that if she didn't enable the console in Firebug, then her script died when she called console.log. That didn't happen for me -- all that happened was that I got error messages in the error console (the one accessed from Firefox's Tools menu, different from the Firebug console). But it's a good idea to check for its existence if you're going to use debugging statements in your code. Like this:

  if (typeof console != "undefined") {
    console.log( "key press, char code " + e.charCode
                + ", key code " + e.keyCode
                + ", " + e.ctrlKey + ", " + e.altKey
		+ ", " + e.metaKey );
  }

Here are some more things you can do with Firebug's console.

Tags: firefox, javascript, programming, tips
[ 16:41 Nov 28, 2009    More tech/web | permalink to this entry | ]

Tip: Bash remembering history across sessions

Two separate friends just had this problem, one of them a fairly experienced Linux user:

You're in bash, history works, but it's not remembered across sessions. Why?

Maybe the size of the history file somehow got set to zero?

$ echo $HISTFILESIZE
500

Nope -- that's not it.

Maybe it's using the wrong file. In bash you can set $HISTFILE to point to different places; for instance, you can use that to maintain different histories per window, or per machine.

$ echo $HISTFILE
/home/username/.bash_history

Nope, that's not it either.

The problem, for both people, turned out to be really simple:

$ ls -l $HISTFILE
-rw------- 1 root root 92 2007-08-20 14:03 /home/user/.bash_history

I'm not sure how it happens, but sometimes the .bash_history file becomes owned by root, and then as a normal user you can't update your history any more.

So a simple

$ rm $HISTFILE

and you're all set -- history across sessions should start working again.

Tags: shell, bash, tips
[ 14:42 Nov 27, 2009    More linux/cmdline | permalink to this entry | ]

Character Sets and Encodings in Linux, part 2

Continuing the discussion of those funny characters you sometimes see in email or on web pages, today's Linux Planet article discusses how to convert and handle encoding errors, using Python or the command-line tool recode:

Mastering Characters Sets in Linux (Weird Characters, part 2).

Tags: writing, linux, unicode, i18n, charsets, ascii, programming, python
[ 15:06 Nov 25, 2009    More writing | permalink to this entry | ]

Google UI Guinea Pigs

A friend wanted help figuring out why suddenly she was seeing a different Google page -- one with a logo that was less 3-dimensional, no drop shadow, and the search text field was in difficult-to-read colors. It was only on one machine, and nobody else she knew was seeing this new page. Was this some sort of Firefox bug? Did I know how she could get back to the old, easier to read Google page?

Fortunately she knew about Firefox's "View page info" menu item (right-click on the page to get it) and used the Media tab there to discover that the logo she was seeing was: http://www.google.com/images/srpr/logo1w.png.

Asking around and googling for things like google logo change or google different search page got me nowhere. It wasn't anything to do with disabling cookies or Javascript -- I tried turning those both off but still didn't see the page she saw (though turning off JS did get rid of the annoying fade-in effect Google started using recently).

Running out of ideas, I Googled for the filename of the logo she was seeing: google logo "logo1w.png" and that turned out to be the answer. I found discussions on reddit and NeoGAF, which led me to articles on SE Roundtable and search Engine Land comparing Google's UI to jazz (you never know what you're going to get next).

Following links eventually led me to an article on the official Googlblog, explaining how Google chooses random users as guinea pigs for trying out new user interfaces.

Unfortunately, none of these articles gave a clue how my friend could opt out of being a guinea pig and get back to a page where the search box colors didn't hurt her eyes.

But it turned out that it's cookie based. So if you find yourself stuck with a Google test page you don't like: Delete all your Google cookies. That did the trick for my friend, and got her back the standard interface.

The Googleblog article (which is full of interesting facts, as Googleblog articles often are) also led me to suggest another tip to her. Apparently a lot of this UI testing is based on how long it takes users to type their query into the search bar. So if you get selected as a test subject and you really dislike the UI they're showing you, typing very slowly might be a way to make it clear that this UI is not working out for you.

Tags: google, user interface
[ 16:03 Nov 24, 2009    More tech/web | permalink to this entry | ]

BAM Indoor R/C Flying

I gather indoor R/C airplane flying is fairly common in some areas of the country. But here in the Bay Area, there's been a lot of demand and not many opportunities to do it, so there was great excitement at a recent opportunity to rent Sunnyvale's community center gym for some Sunnyvale Indoor Flying.

Indoor flying has come a long way. I remember a couple of years ago when most of the indoor planes were either "3-D" planes like my skunk plane that can stay in a small area by hovering, or weirdo concoctions like the Mini IFO. There were a few pioneers who used microminiature actuators and other fancy hardware to build tiny lightweight custom planes, but that was an expensive and difficult proposition.

But lithium-polymer battery technology and advances in tiny servos and brushless motors have created a revolution in super lightweight micro flyers, led by the Parkzone Vapor (Dave's is pictured at right). At a flying weight of half an ounce, the Vapor makes it easy for anybody to fly in a small gym or even a large room.

For folks who want something a little faster and more aerobatic, the Mustang is a bit heavier at 1.2 oz, but still flies well in a gym. And of course, there are the hundreds of micro-helicopters that are popping up everywhere over the last year or two.

Pretty cool stuff! Anyway, we had a great session on Friday flying these planes, and amazingly avoided any serious carnage (unusual for indoor flying where there are so many walls and basketball hoops to smack into). I'm a little out of practice and found the flying a bit intense, so I took a few breaks between flying sessions to shoot photos.

For the new year this is going to turn into an AMA-chartered club, BAM (Bay Area Microflyers). Watch the BayRC forums for more details.

Tags: planes, radio control, indoor flying
[ 15:13 Nov 22, 2009    More misc | permalink to this entry | ]

Of Cima, Sand and Melons

Morningstar Mine

Our first goal of the morning was Morningstar Mine, a set of abandoned mines in the northern part of the preserve.

Two wide, smooth dirt roads leave paved Morningstar Mine Rd to climb the alluvial fan, but the quality of the roads gradually deteriorate over the short distance to the mines.

Morningstar Mine turns out to be a private, going concern, fenced off with NO TRESSPASSING signs. But there are plenty of older, abandoned mines nearby. Very few buildings or mine shafts, but lots of rusting cans and other trash. Really, not much to see, and Dave was in a hurry to move on, so we did.

The Contentious Memorial

Down on Cima Road near the Teutonia Peak trailhead, I wanted to see the famous WWII monument, about which a Supreme Court case is currently raging. (The monument is a cross, a religous symbol, which federal law says should not be supported by government funds or stand on government land.)

I couldn't find anything on the web that gave the location of the monument, so we had to look for it. It turns out that it's easily spotted from the road, atop one of the granite outcrops on the north side of the road, just east of the Teutonia Peak trailhead. (Or see the GPS waypoint file linked at the end of this article.)

In fact, we'd almost certainly seen it before, and shrugged it off as another of those weird inexplicable things you see in the Mojave. The upper part of the cross is currently covered with a box, so it looks like a small sign that says nothing. Several people have put up small flags nearby.

Jackass Canyon -- not to be

The next goal was Jackass Canyon, down in the south part of the preserve west of Kelso.

For quite a while the road is in great shape, hard packed and not badly washboarded. There are lots of curious red anthill-like formations right in the road that turned out to be built not of sand but of some sort of dried plant matter. (Did I mention the curious things you see in the Mojave?)

But then the road descends into a wash full of deep sand with occasional buried rocks. After smacking our undercarriage a couple of times on hidden obstacles while fishtailing around in the sand, we decided retreat was the better part of valor. We'll try Jackass Canyon from the south some time -- maybe it's easier from that direction.

Mojave Rd from 17-Mile Pt to Aiken Mine Rd

Returning to Kelbaker Road, we proceeded a few miles west to 17-Mile Point, where we'd exited the Mojave Road a few days ago, and turned north to complete a section of the Mojave Rd. we hadn't done yet. From Kelbaker to Aiken Mine, the road is quite sandy, with lots of fishtailing, but not a problem for the Rav.

Aiken Mine Rd

This was our second time on Aiken Mine Rd, one of our favorite routes in the preserve.

The lower section of Aiken Mine, from the paved road to the lava tube, is brutally washboarded, like most park dirt roads that get a lot of 2WD traffic.

We didn't stop at the lava tube today, since we'd explored it fairly thoroughly the last time (it's lovely, and provided several of my favorite desktop wallpaper images) but continued straight past it into the basalt.

The ascent from the lower lava fields up to Aiken Mine is weird and wonderful. The road is entirely basalt cinders (Aiken mine is a cinder mine located on a large cinder cone), a mixture of black and red and a little white sand here and there. It's like driving on Mars. The ascent is steep and slightly slippery, but it looks scarier than it is -- there's really no danger here for anything with reasonable clearance, and although 4WD is probably helpful I doubt it's required. The mine, an active cinder mine, is at the top, along with some hiking trails up one of the cinder cones.

Past Aiken, the road descends into the Joshua tree forest on the side of Cima Dome, supposedly the densest Joshua tree forest in the world. ("In the world" should be viewed in light of the fact that Joshua trees don't really exist anywhere outside the Mojave desert of California and Nevada.) More fishtailing in deep sand with a high center groove. The Rav4 never bottomed, but this is definitely not a road to take a 2WD street car of normal ride height.

The melon patch

At some point, the road forks and the left fork seems to be the main one -- but it's a sham. The left fork is actually a power line maintenance road that cuts across to I-15. (We knew this because we'd gotten caught by it the last time, followed the power lines then eventually figured it out and cut back to the more interesting Aiken Mine Rd.)

A few miles afer the powerline fork the road passes a water tank and corral, goes back into sandy Joshua tree forest for a while, then comes out at a strange clearing. What's strange about it? It's a patch of coyote melons. These delicious looking, softball-sized melons apparently grow wild in the Mojave -- but I've never seen them anywhere but this spot. They're apparently all but inedible by humans ... but something eats them, because you can see broken, emptied and dessicated melon rinds lying everywhere.

Did I mention "strange things you see in the Mojave"? Coming on a melon patch in the middle of the desert is one of the things I love about this place.

Alas, the melon patch is almost at the end of the road. Not long after it,, there's a house (I hear one of the rangers lives there) and an intersection, and the road suddenly turns posh for its last mile or two to paved Cima Road.

Photos and GPS Logs

Photos Track log, Waypoints

Tags: mojave, desert, 4wd, rav4, ruins
[ 10:34 Nov 18, 2009    More travel/mojave | permalink to this entry | ]

More on kernel options needed for new X servers

A week ago I wrote about my mouse woes and how they were solved by enabling the "Enable modesetting on intel by default" kernel option.

But all was still not right with X. I could boot into a console, start X, and everything was fine -- but once X was running, I couldn't go back to console mode. Switching to a console, e.g. Ctrl-Alt-F2, did nothing except make the mouse cursor disappear, and any attempt to quit X to go back to my login shell put the monitor in sleep mode permanently -- the machine was still up, and I could ssh in or ctrl-alt-Delete to reboot, but nothing else I did would bring my screen back.

It wasn't strictly an Ubuntu problem, though this showed up with Karmic; I have a Gentoo install on another partition and it had the same problem. And I knew it was a kernel problem, because the Ubuntu kernel did let me quit X.

I sought in vain among the kernel's various Graphics settings. You might think that "enable modesetting" would be related to, you know, being unable to change video modes ... but it wasn't. I tried different DRM options and switching framebuffer on and off. Though, oddly, enabling framebuffer didn't actually seem to enable the framebuffer.

Finally I stepped through the Graphics section of make menuconfig comparing my settings with a working kernel, and saw a couple of differences that didn't look at all important: "Select compiled-in fonts" and "VGA 8x16 font". Silly, but what could they hurt? I switched them on and rebuilt.

And on the next boot, I had a framebuffer, and mode switching.

So be warned: those compiled-in fonts are not optional if you want a framebuffer; and you'd better want a framebuffer, because that isn't optional either if you want to be able to get out of X once you start it.

Tags: linux, intel, X11, kernel
[ 20:22 Nov 16, 2009    More linux/kernel | permalink to this entry | ]

Castle Peaks and Hart: California's Ozymandius

Castle Peaks hiking corridor

Our goal on Tuesday was the "Castle Peaks Hiking Corridor". The Trails Illustrated map showed a side road leading northwest from Walking Box Ranch Rd and eventually petering out to become a hiking trail that went, if not actually to Castle Peaks, at least close enough to get a good look.

Castle Peaks are the rugged spikes you see from I-15 between Mountain Pass and Primm, jutting into the skyline and giving the New York Mountains their appearance of skyscrapers which must be the reason for the range's name. They're eroded fins of eroded Miocene volcanics, surrounded by Precambian metamorphic rocks.

Walking Box Ranch Rd is easy to find off Nipton Rd -- not only is it a prominent, wide dirt road but there's even a road sign, a few miles after the eastern end of the Wee Thump Joshua Tree wilderness (on the north side of Nipton Rd). I'd like to explore Wee Thump and its impressive Joshua trees some day.

The road is good, open and well graded, notwithstanding the humorous "Road not maintained" sign you encounter a few miles in. The side roads follow the map well enough, so it wasn't too difficult to identify the Castle Peaks turn-off. It's a 4-way intersection, not 3-way as shown on the map.

The Castle Peaks road is much narrower and alternates between sandy stretches and dirt. Mostly it's nothing difficult, but the rocky sections are slow going (first gear), there's a high center rut and you cross a couple of washes that make you stop and think about the right line. There are also a couple of sections where the road splits and the higher fork leads to a washed-out chasm, so proceed with due caution.

Eventually the road deteriorated and we parked and continued on foot, along the road and eventually through the gate that marks the Wilderness area boundary. After that the trail crosses through an area of basalt breccia -- the northwestern limit of the "malpais" lava area concentrated around Malpais Springs.

The icy wind dissuaded us from trying to go all the way to Castle Peaks (the trail doesn't go there anyway) but we did get a good view of them as well as nice views of Joshua trees and the malpais.

After our hike, we retraced our steps and crossed over along smooth, good roads to the deserted Hart townsite.

Hart Site: Ozymandius in the Mojave

Hart was a mining town established in 1907. At its peak it had five hotels, 8 saloons, a newspaper and about 400 residents. And today, what you can see of the town is ... a lot of rusted cans.

That's all. No buildings. No walls. But I guess when Hart's residents departed, they left their trash behind, and scattered among the yucca and creosote you can find collections of rusted cans and a few glass bottles darkening in the desert sun.

It's sobering. What happened to all the buildings? Where are those hotels and saloons and hundreds of houses? Apparently if you search long enough, you can find a few tiny segments of walls -- but mostly, this boom town has crumbled into nothingness. And trash.

It reminds me of Percy Bysshe Shelley's Ozymandius:

And on the pedestal these words appear:
"My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!"
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away

There's no shattered visage -- just a plaque giving the history of the town, the expansive pit mine nearby, and the garbage quietly rusting away in the lone and level sands.

Photos and GPS log:

Photos
Track log
Waypoints

Tags: mojave, desert, 4wd, rav4, ruins
[ 14:03 Nov 14, 2009    More travel/mojave | permalink to this entry | ]

Article: Character Sets and Encodings in Linux

or: Why do I See All Those Those Weird Characters?

Today's Linux Planet article concerns those funny characters you sometimes see in email or on web pages, like when somebody puts “random squiggles’ around a phrase when they probably meant “double quotes”:

Character Sets in Linux or: Why do I See Those Weird Characters?.

Today's article covers only what users need to know. A followup article will discuss character encoding from a programmer's point of view.

Tags: writing, linux, unicode, i18n, charsets, ascii
[ 16:34 Nov 12, 2009    More writing | permalink to this entry | ]

Building a Py-Webkit-GTK presentation tool

I almost always write my presentation slides using HTML. Usually I use Firefox to present them; it's the browser I normally run, so I know it's installd and the slides all work there. But there are several disadvantages to using Firefox:

• In fullscreen mode, it has a small "minimized urlbar" at the top of the screen that I've never figured out to banish -- not only is it visible to users, but it also messes up the geometry of the slides (they have to be 762 pixels high rather than 768);
• It's very heavyweight, bad when using a mini laptop or netbook;
• Any personal browsing preferences, like no-animation, flashblock or noscript, apply to slides too unless explicitly disabled, which I've forgotten to do more than once before a talk.

Last year, when I was researching lightweight browsers, one of the ones that impressed me most was something I didn't expect: the demo app that comes with pywebkitgtk (package python-webkit on Ubuntu). In just a few lines of Python, you can create your own browser with any UI you like, with a fully functional content area. Their current demo even has tabs.

So why not use pywebkitgtk to create a simple fullscreen webkit-based presentation tool?

It was even simpler than I expected. Here's the code:

#!/usr/bin/env python
# python-gtk-webkit presentation program.
# Copyright (C) 2009 by Akkana Peck.
# Share and enjoy under the GPL v2 or later.

import sys
import gobject
import gtk
import webkit

class WebBrowser(gtk.Window):
    def __init__(self, url):
        gtk.Window.__init__(self)
        self.fullscreen()

        self._browser= webkit.WebView()
        self.add(self._browser)
        self.connect('destroy', gtk.main_quit)

        self._browser.open(url)
        self.show_all()

if __name__ == "__main__":
    if len(sys.argv) <= 1 :
        print "Usage:", sys.argv[0], "url"
        sys.exit(0)

    gobject.threads_init()
    webbrowser = WebBrowser(sys.argv[1])
    gtk.main()

That's all! No navigation needed, since the slides include javascript navigation to skip to the next slide, previous, beginning and end. It does need some way to quit (for now I kill it with ctrl-C) but that should be easy to add.

Webkit and image buffering

It works great. The only problem is that webkit's image loading turns out to be fairly poor compared to Firefox's. In a presentation where most slides are full-page images, webkit clears the browser screen to white, then loads the image, creating a noticable flash each time. Having the images in cache, by stepping through the slide show then starting from the beginning again, doesn't help much (these are local images on disk anyway, not loaded from the net). Firefox loads the same images with no flash and no perceptible delay.

I'm not sure if there's a solution. I asked some webkit developers and the only suggestion I got was to rewrite the javascript in the slides to do image preloading. I'd rather not do that -- it would complicate the slide code quite a bit solely for a problem that exists only in one library.

There might be some clever way to hack double-buffering in the app code. Perhaps something like catching the 'load-started' signal, switching to another gtk widget that's a static copy of the current page (if there's a way to do that), then switching back on 'load-finished'.

But that will be a separate article if I figure it out. Ideas welcome!

Update, years later: I've used this for quite a few real presentations now. Of course, I keep tweaking it: see my scripts page for the latest version.

Tags: programming, hack, python, web, speaking
[ 17:12 Nov 11, 2009    More programming | permalink to this entry | ]

Mouse failures with 2.6.31, Karmic and Intel

I've been seeing intermittent mouse failures since upgrading to Ubuntu 9.10 "Karmic". At first, maybe one time out of five I would boot, start X, and find that I couldn't move my mouse pointer. But after building a 2.6.31.4 kernel, things got worse and it happened nearly every time.

It wasn't purely an X problem; if I enabled gpm, the mouse failed in the console as well as in X. And it wasn't hardware, because if I used Ubuntu 9.10's standard kernel, my mouse worked every time.

After much poking around with kernel options, I discovered that if I tunred off the Direct Rendering manager ("Intel 830M, 845G, 852GM, 855GM, 865G (i915 driver)"), my mouse would work. But that wasn't a satisfactory solution; aside from not being able to run Google Earth, it seems that Intel graphics needs DRM even to get reasonable performance redrawing windows. Without it, every desktop switch means watching windows slowly redraw over two or three seconds.

(Aside: why is it that Intel cards with shared CPU memory need DRM to draw basic 2-D windows, when my ancient ATI Radeon cards without shared memory had no such problems?)

But I think I finally have it nailed. In the kernel's Direct Rendering Manager options (under Graphics), the "Intel 830M, 845G, 852GM, 855GM, 865G (i915 driver)" using its "i915 driver" option has a new sub-option: "Enable modesetting on intel by default".

The help says:

CONFIG_DRM_I915_KMS:
Choose this option if you want kernel modesetting enabled by default, and you have a new enough userspace to support this. Running old userspaces with this enabled will cause pain. Note that this causes the driver to bind to PCI devices, which precludes loading things like intelfb.

Sounds optional, right? Sounds like, if I want to build a kernel that will work on both karmic and jaunty, I should leave that off so as not to "cause pain".

But no. It turns out it's actually mandatory on karmic. Without it, there's a race condition where about 80-90% of the time, hal won't see a mouse device at all, so the mouse won't work either in X or even on the console with gpm.

It's sort of the opposite of the "Remove sysfs features which may confuse old userspace tools" in General Setup, where the name implies that it's optional on new distros like Karmic, but in fact, if you leave it on, the kernel won't work reliably.

So be warned when configuring a kernel for brand-new distros. There are some new pitfalls, and options that worked in the past may not work any longer!

Update: see also the followup post for two more non-optional options.

Tags: linux, ubuntu, intel, X11, kernel
[ 23:34 Nov 10, 2009    More linux/kernel | permalink to this entry | ]

Friendlier error messages for shell newbies

Helping people get started with Linux shells, I've noticed they tend to make two common mistakes vastly more than any others:

1. Typing a file path without a slash, like etc/fstab
2. typing just a filename, without a command in front of it

The first boils down to a misunderstanding of how the Linux file system hierarchy works. (For a refresher, you might want to check out my Linux Planet article Navigating the Linux Filesystem.)

The second problem is due to forgetting the rules of shell grammar. Every shell sentence needs a verb, just like every sentence in English. In the shell, the command is the verb: what do you want to do? The arguments, if any, are the verb's direct object: What do you want to do it to?

(For grammar geeks, there's no noun phrase for a subject because shell commands are imperative. And yes, I ended a sentence with a preposition, so go ahead and feel superior if you believe that's incorrect.)

The thing is, both mistakes are easy to make, especially when you're new to the shell, perhaps coming from a "double-click on the file and let the computer decide what you should do with it" model. The shell model is a lot more flexible and (in my opinion) better -- you, not the computer, gets to decide what you should do with each file -- but it does take some getting used to.

But as a newbie, all you know is that you type a command and get some message like "Permission denied." Why was permission denied? How are you to figure out what the real problem was? And why can't the shell help you with that?

And a few days ago I realized ... it can! Bash, zsh and similar shells have a fairly flexible error handling mechanism. Ubuntu users have seen one part of this, where if you type a command you don't have installed, Ubuntu gives you a fancy error message suggesting what you might have meant and/or what package you might be missing:

$ catt /etc/fstab
No command 'catt' found, did you mean:
 Command 'cat' from package 'coreutils' (main)
 Command 'cant' from package 'swap-cwm' (universe)
catt: command not found

What if I tapped into that same mechanism and wrote a more general handler that could offer helpful suggestions when it looked like the user forgot the command or the leading slash?

It turns out that Ubuntu's error handler uses a ridiculously specific function called command_not_found_handle that can't be used for other errors. Some helpful folks I chatted with on #bash felt, as I did, that such a specific mechanism was silly. But they pointed me to a more general error trapping mechanism that turned out to work fine for my purposes.

It took some fussing and fighting with bash syntax, but I have a basic proof-of-concept. Of course it could be expanded to cover a lot more types of error cases -- and more types of files the user might want to open.

Here are some sample errors it catches:

$ schedule.html
bash: ./schedule.html: Permission denied

schedule.html is an HTML file. Did you want to run: firefox schedule.html

$ screenshot.jpg
bash: ./screenshot.jpg: Permission denied

screenshot.jpg is an image file. Did you want to run:
    pho screenshot.jpg
    gimp screenshot.jpg

$ .bashrc
bash: ./.bashrc: Permission denied

.bashrc is a text file. Did you want to run:
    less .bashrc
    vim .bashrc

$ ls etc/fstab
/bin/ls: cannot access etc/fstab: No such file or directory

Did you forget the leading slash?
etc/fstab doesn't exist, but /etc/fstab does.

You can find the code here: Friendly shell errors and of course I'm happy to take suggestions or contributions for how to make it friendlier to new shell users.

Tags: linux, shell, help, education, programming
[ 15:07 Nov 08, 2009    More linux | permalink to this entry | ]

Probing the Limits of a Rav4 on Clark Mountain

The plan

Just west of Primm and north of Yates Well lies a small, disconnected piece of Mojave National Preserve called Clark Mountain.

A year or two ago, Dave and I tried to explore Clark Mountain. Exiting I-15 at Cima Road, we headed northwest and looked for a small unmarked road heading east into the park. But we missed the right road and ended up on a rocky, tedious power-line road. Eventually we took a side road heading toward the mountain and ended up in a maze of unmarked roads, eventually coming to a four-way intersection with a sign:

GREEN'S WELL ROAD
Public by-pass route

Unfortunately, one of the three roads dead-ended in a "Private property: KEEP OUT" sign while the other two looked too technical to attempt so late in the afternoon. So we slunk back to the powerline road and turned right, toward Primm.

This year, we attacked Clark Mountain from the other side.

Old Ivanpah

We started from Yates Well Rd, the first I-15 exit south of Primm. Right toward the golf course, then first left toward the mountain. Our first project was to find old Ivanpah.

Ivanpah is an abandoned town over in the main part of Mojave Preserve -- but historical records show that it was moved there from an earlier location over on the slopes of Clark.

Just inside the NPS boundary, there's a network of small dirt roads forking off to the left. We parked and walked around, and eventually found the Ivanpah site: a few standing rock walls, a watering trough, a mysterious hole in the ground with a fence around it ("Private property, KEEP OUT") and a collection of ancient rusted and flattened iron cans as well as more modern shotgun shells.

Colosseum Gorge

Beyond Old Ivanpah, the road threads its way up along Colosseum Gorge, named after the spectacular open-pit mine near the top of the pass. The mine's steeply terraced walls do put one in mind of a vast spectator arena; but the only show today was the quiet pool at the bottom, the only spectators the two of us and a trio of ravens.

There's a network of interesting looking roads below the mine. Some lead up to Clark while others explore the grassy meadow below. A couple in a Landrover (the only other vehicle we saw all day) was crawling along one of the mountain roads.

Continuing on from the mine, we found the road occasionally rocky, but easy. At the bottom was an intersection with a sign aimed westward:

GREEN'S WELL ROAD
Public by-pass route

We'd made the connection! We'd been so close on our previous trip -- if only we'd known.

Clark Mountain, West

The rest of the journey would be easy! Just turn left at the right place and head south along the west face of Clark to the paved road, avoiding that awful rocky powerline road which had so sapped our energy and our time on the previous trip.

The turn-off (shown at left) is easy to miss: a fork to the left, up a steep incline, then an immediate right (fortunately shown on our Trails Illustrated map). We drove right past the left at first thinking it couldn't be the one, but as we saw our route bending right and down toward the powerline now visible in the distance, we knew we'd missed it and went back.

We climbed out of desert willow into a Joshua tree forest with a beautiful view of the valley to the north. And then the road got rocky. Just as rocky as it had been on the powerline road -- but this time it hummocked up over hills and down into washes, so the going was much more technical.

It turned out to be by far the most technical road we'd done, involving frequent stops to get out and plan routes and sometimes build ramps so the Rav wouldn't bottom out. On the tricky sections, one person got out and "spotted" while the other drove.

In the end we made it across to paved Kingston Rd with no damage to the Rav. That section only took about two and a half hours, but it felt like five. I guess it was a learning experience, certainly the most technical road we've done -- but in future we'll stay off the west side of Clark Mountain.
(At right: View of Primm and Ivanpah dry lake.)

GPS log:

Track log, Waypoints

Photos:

Photos

Tags: mojave, desert, 4wd, rav4
[ 14:44 Nov 06, 2009    More travel/mojave | permalink to this entry | ]

Autologin changes again for Ubuntu Karmic

The syntax to log in automatically (without gdm or kdm) has changed yet again in Ubuntu Karmic Koala. It's similar to the Hardy autologin, but the file has moved: under Karmic, /etc/event.d is no longer used, as documented in the releasenotes (though, confusingly, it isn't removed when you upgrade, so it may still be there taking up space and looking like it's useful for something). The new location is /etc/init/tty1.conf. So here are the updated instructions:

Create /usr/bin/loginscript if you haven't already, containing something like this:

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

Then edit /etc/init/tty1.conf and look for the respawn line, and replace the line after it, exec /sbin/getty -8 38400 tty1, with this:

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

As far as I know, it's safe to delete /etc/event.d since it's now unused. I haven't verified that yet. Better rename it first, and see if anything breaks.

Tags: linux, ubuntu, boot
[ 20:46 Nov 02, 2009    More linux/install | permalink to this entry | ]

Controlling brightness on a Sony laptop in Linux 2.6.31

My laptop, a Sony Vaio TX650P, badly needed a kernel update. 2.6.28.3 had been running so well that I just hadn't gotten around to changing it. When I finally updated to 2.6.31.5, nearly everything worked, with one exception: Fn-F5 and Fn-F6 no longer adjusted screen brightness.

I found that there were lots of bugs filed on this problem -- kernel.org bug 12816, Ubuntu bug 414810, Fedora bug 519105 and so on. A few of them had terse comments like "Can you try this patched binary release?" but none of them had a source patch, or any hints as to the actual nature of the problem.

But one of them did point me to /sys/class/backlight. In my working 2.6.28.3 kernel, that directory contained a sony subdirectory containing useful files that let me query or change the brightness: echo 1 >/sys/class/backlight/sony/brightness
On my nonworking 2.6.31.5 kernel, I had /sys/class/backlight but there was no sony subdirectory there.

grep SONY .config in the two kernels revealed that my working kernel had SONY_LAPTOP set, while the nonworking one did not. No problem! Just figure out where SONY_LAPTOP is in the configuration (it turns out to be at the very end of "device drivers" under "X86 Platform Specific Device Drivers"), make menuconfig, set SONY_LAPTOP and rebuild ... right?

Well, no. make menuconfig showed me lots of laptop manufacturers in the "Platform Specific" category, but Sony wasn't one of them. Of course, since it didn't show the option it also didn't offer a chance to read the help for the option either, which might have told me what its dependencies were.

Time for a recursive grep of kernel source: grep -r SONY_LAPTOP .
arch/x86/configs/i386_defconfig told me the option did indeed still exist, and where to find it. drivers/platform/x86/Kconfig lists the option itself, and says it depends on INPUT and RFKILL.

RFKILL? A bit more poking around located that one near the end of "Networking support", with the name "RF switch subsystem support". (I love how user-visible names for kernel options only marginally resemble the CONFIG names.) It's apparently intended for "control over RF switches found on many WiFi and Bluetooth cards," something I don't seem to need on this laptop (my WiFi works fine without it) -- except that the kernel for some reason won't let me build the ACPI brightness control without it.

So that's the secret. Go to "Networking support", set "RF switch subsystem support", then back up to "Device drivers", scroll down to the end to find "X86 Platform Specific Device Drivers" and inside it you'll now see "Sony Laptop Extras". Enable that, and the Fn-F5/F6 keys (as well as /sys/class/backlight/sony/brightness) will work again.

Tags: linux, kernel, sony, laptop
[ 10:07 Nov 02, 2009    More linux/kernel | permalink to this entry | ]

Turning off the Gnome Keyring prompt

My mom got a netbook! A ZaReason Terra, in lovely metallic brown. (I know "metallic brown" sounds odd -- I was skeptical before I saw it -- but take it from me, it looks great.) It's cute and lightweight, with a nice keyboard with a clicky IBM-keyboard-style feel, and a meta key with a Tux penguin on it rather than a silly Windows logo. The only criticism so far is that the comma and period keys are narrower than the rest, so all three of us keep hitting slash when we mean period.

It comes preinstalled with Ubuntu (currently 9.04 Jaunty) with a full Gnome desktop. I've never been much of a Gnome fan, but this time we thought we'd try keeping it for a while and see how Mom likes it. We can always switch to something faster, like Openbox, later.

Of course, a lot of things needed configuration, like getting rid of one of the two toolbars. (In this age of cinema-width screens, why is it that the major desktops, like Gnome and even Apple, insist on sucking away vertical space with multiple menubars/toolbars?)

(And don't get me started on Evolution's preferences panes that are too big to fit on a netbook screen, yet have no scrollbars; and although the preference window is resizable, Gnome won't let you drag a window past the top of the screen so you can resize it taller.)

What stymied us, though, was the Gnome keyring and the way it prompts you for a password -- even if you've already typed in a login password -- whenever it tries to connect to the wireless network.

Web searches revealed that we were far from the only people who found this annoying and wanted to turn it off. There are lots of howtos. Unfortunately, every howto is different -- apparently gnome-keyring changes its user interface with every release, but somehow none of these UI changes ever make it easier to find your way to the place where you can turn off the password prompting. So here's one for Jaunty.

Howto turn off the Gnome-keyring master password in Ubuntu Jaunty

The key is a program called "seahorse", which you can get to via Applications->Accessories->Password and Encryption Keys. Click on the Passwords tab: you'll probably see two lines, login password and master password. According to some of the earlier howtos, these two passwords need to be the same in order for the following steps to work.

Right-click on login password and choose Unlock (I'm not sure if that step is necessary, but we did it).

Then from the same right-click menu, choose Change Password and make the new password empty. Of course, it will warn you about this horribly insecure behavior and how you're an idiot to want to do this. Your choice!

Tags: linux, gnome, ui
[ 15:31 Nov 01, 2009    More linux | permalink to this entry | ]