Shallow Thoughts : : Feb

SCALE9x

Talks

A few standout talks:

Leigh Honeywell's keynote was a lively and enjoyable discussion of hackerspaces -- from the history of the movement to a discussion of some of the coolest and most innovative hackerspaces around today. She had plenty of stories and examples that left everyone in the audience itching to get involved with a local hackerspace, or start one if necessary.

John Wise and Eugene Clement of LinuxAstronomy.com presented the entertaining "A Reflection on Classroom Robotics with Linux Robots in classrooms". They've taught kids to build and program robots that follow lines, solve mazes, and avoid obstacles. The students have to figure out how to solve problems, details like when and how far to back up. What a fantastic class! I can't decide if I'd rather teach a class like that or take it myself ... but either way, I enjoyed the presentation. They also had a booth in the exhibit hall where they and several of their students presented their Arduino-based robots exploring simulated Martian terrain.

Jonathan Thomas spoke about his OpenShot video editor and the development community behind it, with lots of video samples of what OpenShot can do. Sounds like a great program and a great community as well: I'll definitely be checking out OpenShot next time I need to edit a video.

It's worth mentioning that both the robotics talk and the OpenShot one were full of video clips that ran smoothly without errors. That's rare at conferences -- videos so often cause problems in presentations (OpenOffice is particularly bad at them). These presenters made it look effortless, which most likely points to a lot of preparation and practice work beforehand. Good job, guys!

Larry Bushey's "Produce An Audio Podcast Using Linux" was clear and informative, managing to cover the technology, both hardware and software, and the social factors like how often to broadcast, where to host, and how to get the word out and gain and keep listeners while still leaving plenty of time for questions.

The Exhibit Hall

In between talks I tried to see some of the exhibit hall, which was tough, with two big rooms jam-packed with interesting stuff.

Aside from LinuxAstronomy and their robots, there were several other great projects for getting technology into schools: Partimus from the bay area, and Computers4Kids more local to LA, both doing excellent work.

The distro booths all looked lively. Ubuntu California's booth was always so packed that it was tough getting near to say hi, Fedora was well attended and well stocked with CDs, and SuSE had a huge array of givaways and prizes. Debian, Gentoo, Tiny Core and NetBSD were there as well.

Distro Dilemma and "the Hallway track"

Late in the game I discovered even Arch Linux had a booth hidden off in a corner. I spent some time there hoping I might get help for my ongoing Arch font rendering problem, but ended up waiting a long time for nothing. That left me with a dilemma for my talk later that day: Arch works well on my laptop except that fonts sometimes render with chunks missing, making them ugly and hard to read; but a recent update of Ubuntu Lucid pulled in some weird X change that keeps killing my window manager at unpredictable times. What a choice! In the end I went with Ubuntu, and indeed X did go on the fritz, so I had to do without my live demo and stick to my prepared slides. Not a tragedy, but annoying. The talk went well otherwise.

I had a great conversation with Asheesh from the OpenHatch project about how to make open source projects more welcoming to new contributors. It's something I've always felt strongly about, but I feel powerless to change existing projects so I don't do anything. Well, OpenHatch is doing something about it, and I hope I'll be able to help.

The Venue

Not everything was perfect. The Hilton is a new venue for SCALE, and there were some issues. On Saturday, every room was full, with people lining the walls and sitting on floors. This mostly was not a room size problem, merely a lack of chairs. Made me wonder if we should go all opensource on them and everybody bring their own lawn chair if the hotel can't provide enough.

Parking was a problem too. The Hilton's parking garage fills up early, so plan on driving for ten minutes through exhaust-choked tunnels hoping to find a space to squeeze into. We got lucky, so I didn't find out if you have to pay if you give up and exit without finding a spot.

Then Sunday afternoon they ran short of validation tickets (the ones that reduce the cost from $22 to $9), and it wasn't clear if there was any hope of more showing up (eventually some did).

To top it off, when we finally left on Sunday the payment machine at the exit swallowed my credit card, requiring another 15 minutes of waiting for someone to answer the buzzer. Eventually the parking manager came down to do a magic reset rite.

So I didn't come away with a great impression of the Hilton. But it didn't detract much from a wonderful conference full of interesting people -- I had a great time, and would (and do) recommend SCALE to everyone with any interest in Linux. But it left me musing about the pros and cons of different venues ... a topic I will discuss in a separate post.

Article: Building kernels for plug computers

It covers how to find and install a cross-compiler (sadly, your Linux distro probably doesn't include one), configuring the Linux kernel build, and a few gotchas and things that I've found not to work reliably.

It took me a lot of trial and error to figure out some of this -- there are lots of howtos on the web but a lot of them skip the basic steps, like the syntax for the kernel's CROSS_COMPILE argument -- but you'll need it if you want to enable any unusual drivers like GPIO. So good luck, and have fun!

Python for (Cartalk) Puzzlers

Last week's Car Talk had a fun puzzler called "Three Pieces of Paper":

Three different numbers are chosen at random, and one is written on each of three slips of paper. The slips are then placed face down on the table. The objective is to choose the slip upon which is written the largest number.

Here are the rules: You can turn over any slip of paper and look at the amount written on it. If for any reason you think this is the largest, you're done; you keep it. Otherwise you discard it and turn over a second slip. Again, if you think this is the one with the biggest number, you keep that one and the game is over. If you don't, you discard that one too.

What are the odds of winning? The obvious answer is one in three, but you can do better than that. After thinking about it a little I figured out the strategy pretty quickly (I won't spoil it here; follow the link above to see the answer). But the question was: how often does the correct strategy give you the answer?

It made for a good "things to think about when trying to fall asleep" insomnia game. And I mostly convinced myself that the answer was 50%. But probability problems are tricky beasts (witness the Monty Hall Problem, which even professional mathematicians got wrong) and I wasn't confident about it. Even after hearing Click and Clack describe the answer on this week's show, asserting that the answer was 50%, I still wanted to prove it to myself.

Why not write a simple program? That way I could run lots of trials and see if the strategy wins 50% of the time.

So here's my silly Python program:

#! /usr/bin/env python

# Cartalk puzzler Feb 2011

import random, time

random.seed()

tot = 0
wins = 0

while True:
    # pick 3 numbers:
    n1 = random.randint(0, 100)
    n2 = random.randint(0, 100)
    n3 = random.randint(0, 100)

    # Always look at but discard the first number.
    # If the second number is greater than the first, stick with it;
    # otherwise choose the third number.
    if n2 > n1 :
        final = n2
    else :
        final = n3

    biggest = max(n1, n2, n3)
    win = (final == biggest)
    tot += 1
    if win :
        wins += 1
    print "%4d %4d %4d %10d %10s %6d/%-6d = %10d%%" % (n1, n2, n3, final,
                                                       str(win),
                                                       wins, tot,
                                                       int(wins*100/tot))
    if tot % 1000 == 0:
        print "(%d ...)" % tot
        time.sleep(1)

It chooses numbers between 0 and 100, for no particular reason; I could randomize that, but it wouldn't matter to the result. I made it print out all the outcomes, but pause for a second after every thousand trials ... otherwise the text scrolls too fast to read.

And indeed, the answer converges very rapidly to 50%. Hurray!

After I wrote the script, I checked Car Talk's website. They have a good breakdown of all the possible outcomes and how they map to a probability. Of course, I could have checked that first, before writing the program. But I was thinking about this in the car while driving home, with no access to the web ... and besides, isn't it always more fun to prove something to yourself than to take someone else's word for it?

GIMP: Don't get confused by the Auto button

In at least one case, it was a setting most of us had forgotten about: the Auto button. It's easy to miss, but if you turn it on accidentally, you may be unable to do anything in GIMP until you realize what's happened.

The Auto button is the one at the upper right of your Layers dialog. It's on by default, and what it does is ensure that dialogs like Layers, and GIMP's notion of the currently active layer, follow the active image. Open a new image, or click in a different image window, and your Layers dialog switches images -- so whatever you do next will apply to the image you just chose.

If you turn Auto off, then by default, no image and no layer is active. Notice, in the screenshot at left, how no image is shown in the option menu just left of the Auto button.

Even if you open a new image, you can't do anything with it until you explicitly choose an image from the menu.

I'm sure you can see why this could be confusing. So why have that button at all?

Well, it's useful when you're working with lots of images -- for instance, if you want to drag a layer from one image into another image, you can use the menu to switch quickly among images and layers without needing to bring those image windows to the front. I don't find I need it, but for those who do, I guess it can be a real time-saver.

Just to make it even more confusing, not everyone even has the Auto button or the menu next to it. You can turn it off (and gain a little extra vertical space for your layers dialog) with the tiny menu button right above the mode menu. "Show Image Selection" controls whether the image option menu, and the Auto button next to it, will be displayed. "Auto Follow Active Image" is the same toggle as the Auto button itself.

So if you ever get stuck and the Layers dialog doesn't seem to be showing layers from your image, and you can't figure out why ... remember that pesky Auto button. It might just be the problem.

(If not, try quitting GIMP and moving your profile aside. That works for curing all manner of mysterious ills -- including this one. Come to think of it, that deserves an article of its own. Coming soon!)

New GIMP Arrow Designer

So I fixed it. You can get the new Arrow Designer 0.5 on my GIMP Arrow Designer page.

It's purely a coincidence that I discovered this a week before SCALE, where I'll be speaking on Writing GIMP Scripts and Plug-Ins. Arrow Designer is one of my showpieces for making interactive plug-ins with GIMP-Python, so I'm glad I noticed the bug when I did.

Starting a line with a slash in xchat

/join #channel

/me waves to everyone

Great, but what if I want to start a line with a slash?

On some IRC clients, you can type two slashes, e.g.

/ /me tries

On xchat, what you need is /say:

/say /me succeeds!

Silly little tip, but I know I'll forget it if I don't record it ... and I bet I'm not the only xchat user wondering how to do this.

//me tries

Unbricking Plug Computers

Here it is: Un-Bricking Linux Plug Computers: uBoot, iBoot, We All Boot for uBoot.

If you want more exhaustive detail, particular on those uBoot scripts and how they work, I go through some of the details in a brain-dump I wrote after two weeks of struggling to unbrick my first GuruPlug: Building and installing a new kernel for a SheevaPlug. But don't worry if that page isn't too clear; I'll cover the kernel-building part more clearly in my next LinuxPlanet article on Feb. 24.

Quick tip: Disabling version control in Emacs

It wasn't obvious what keywords to search for, but I finally found a combination, emacs prevent OR disable autoload vc (the vc was the important part), which led me to the solution (found on this page):

;; Disable all version control
(setq vc-handled-backends nil)

Files load much faster now!