Gallery2 vs Facebook

I have a Gallery2 installation where I put pictures online. The rest of the world from where I sit seems to prefer facebook. Google seems to suggest there’s a plugin / facebook app that can make these two play nice together. More once I’ve tried it.

Update 2009.09.17. I tried this a few weeks ago, successfully.

There’s a Facebook developer’s wiki page about it.

There’s also a Facebook application page about it.

Basically, you have to add one PHP file to your Gallery2 installation. It’s not a very long file and it seems to only read things from the database as user “guest” so I hope that means it’s pretty safe. It does enable pretty straightforward imports to facebook. Best I’ve seen so far.

I’d like for it to be able to send metadata the other direction. For example, once people have tagged themselves in the photos on facebook, push their names back to the Gallery2 installation.

Wheel weights

Useful list.

emacs slow startup

I’ve become annoyed that emacs seems to take ever longer to startup. This is the result of about 6 years of piecemeal edits by an unqualified lisp programmer (me) applied to a .emacs file that was dubious to begin with.

This thread proposed a fix which worked for me! Add the following to the beginning of your .emacs:

(modify-frame-parameters nil '((wait-for-wm . nil)))

XySSL is now PolarSSL

I frequently tout Christophe Devine’s XySSL library because it implements commonly-used cryptographic primitives in a concise, low-dependency package. I’ve used XySSL as the crypto libraries in many of my research projects.

A while ago the XySSL website disappeared and I became despondent. However, I have recently learned that the same great code is back as part of PolarSSL, at
polarssl.org. Check it out!

$1$ vs $6$ in /etc/shadow

I recently discovered by surprise that the entries in /etc/shadow changed format in Ubuntu 8.10. It took some searching to track down what has changed and why, so I summarize my findings here.

The hash algorithm has changed to sha512, which is indicated by the $6$.

In the file /etc/pam.d/common-password, there was a line like so:

password [success=1 default=ignore] pam_unix.so obscure sha512

Changing it to:

password [success=1 default=ignore] pam_unix.so obscure md5

causes newly updated passwords to assume the old $1$ format. Don’t do this without a good reason as sha512 is definitely the better algorithm, but at least now the change makes sense.

Partitioning from the command line

CLI Partitioning is a great place to start. Note that it’s also possible to resize a “dirty” NTFS volume, though of course the risk of losing data goes up. I generally do this when getting a new machine that comes with Windows pre-installed, because it’s less work than possibly re-installing windows some time in the future.

USB to Ethernet adapters

I went through some pain to figure out some USB to Ethernet adapters that work reasonably well on Linux. The pain was primarily derived from needing several dozen of them, not being able to definitively test anything without actually getting my hands on them, and getting bad information from various vendors about how many devices are in stock.

Linksys USB200M – works fine but has a fragile ethernet connector. Uses “ASIX” driver for ax8817x.

Linksys USB300M – also works fine and has a nice short cord to provide strain relief for the connectors. Uses “ASIX” driver for ax88772 (not ax88772a).

Sabrent “USB 2.0 TO Fast Ethernet” (their capitalization), NT-USB20 – seems to work fine, no fragile connectors, but no cord either so one could conceivably damage the usb port on a laptop if the cable gets a yank. Uses “pegasus” driver.

Summer 2009 Event Plans

Not necessarily in this order:

• Grass Roots Racing G.R.A.S.S. Series Apr 18, Jun 13, Jul 18, Aug 15, Sep 19
• Rachel Carson Challenge Jun 20
• Pittsburgh Triathlon Jul 26
• Philly LiveStrong Challenge Aug 23
• 24 hours of 7 Springs Sep 5
• Bike the Katy Train in Missouri TBD

GPIO on a Gumstix Console VX

Every embedded-style project begins by blinking LEDs. Once the LEDs blink, anything is possible.

My platform is the Gumstix starter pro pack, which includes a “verdex XM4″ main board, and the “console vx” expansion board. I was initially thinking I would hijack one of the serial ports, so I started looking at the docs for the Gumstix UARTS. However, I’m trying to do this with as little change to the default software environment as possible, and the default environment does not include a terminal program (e.g., minicom). Likewise, some tests of the serial ports using “echo” and “cat” did not impress.

Thus, I changed my focus to the general purpose I/O (GPIO) through-holes on the console vx. I found this discussion where people are trying to achieve something similar with the console LCD expansion board, which is actually quite similar to my console vx. The critical information, though, was that there is such a directory as /proc/gpio, and that echo and cat are sufficient to interact with the files contained therein. I followed the advice in that discussion and started with the AC97 header. These schematics were helpful in learning what went where, as was Table 4.1 in the Table 4.1 in the PXA255 Processor Developer’s Manual.

Looking at the bottom of the console vx board, the AC97 header has two rows of 4 pins, and the top-right one has a square solder pad (as opposed to the others, which are round). I deduced that the square hole was ground. Here is an ASCII diagram of which GPIO pins go to which through-holes:

?,30,29,GND
31,?,?,28

Thus, to set and clear one of pins 28-31, one would enter the following at the command prompt:
$ echo “GPIO out set” > /proc/gpio/GPIO28
$ echo clear > /proc/gpio/GPIO28

The string “GPIO out” tells the system to put this pin into the “GPIO mode”. Most of the pins also have alternate functions, so this is necessary. During a boot cycle, the pins seem to “remember” that they are in GPIO mode and set to ‘out’, so those can be omitted after the first invocation.

Firmware updates for AMD CPUs

AMD has recently decided to add support for updating the firmware on its processors on amd64.org. The Linux instructions simply say that the “Microcode update for AMD processors uses the firmware loading infrastructure.” I wasn’t familiar with the firmware loading infrastructure, and it took some serious detective work to figure things out.

I did `aptitude install firmware-tools`

I then noticed (since firmware-tools does not appear to have any meaningful documentation) that /etc/firmware now exists. I then found
this message suggesting that the firmware should live in /etc/firmware, and this message suggesting a directory structure of amd-ucode/microcode_amd.bin. Well, that didn’t work. I received errors to the tune of:


microcode: CPU0: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU1: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU2: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
microcode: CPU3: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: failed to load file amd-ucode/microcode_amd.bin
Microcode Update Driver: v2.00 , Peter Oruba


I then ran a simple ‘locate firmware’ command and saw many instances in /lib/firmware. I moved amd-ucode/microcode_amd.bin into that directory, and received more meaningful feedback in `dmesg` (following rmmod microcode; modprobe microcode`):


microcode: CPU0: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU0: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU0: updated (new patch_level=0x1000083)
microcode: CPU1: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU1: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU1: updated (new patch_level=0x1000083)
microcode: CPU2: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU2: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU2: updated (new patch_level=0x1000083)
microcode: CPU3: patch_level=0x1000065
platform microcode: firmware: requesting amd-ucode/microcode_amd.bin
microcode: size 1936, total_size 960
microcode: CPU3: patch mismatch (processor_rev_id: 1020, equiv_cpu_id: 1022)
microcode: size 968, total_size 960
microcode: CPU3: updated (new patch_level=0x1000083)
Microcode Update Driver: v2.00 , Peter Oruba


It still doesn’t look perfect (i.e., it thinks the particular .bin file is not right for my CPU), but at least now I think I’m using the “firmware loading interface” successfully.

Many links to http://www.urbanmyth.org/microcode/ were also provided, but that site seems to be Intel-only.

UPDATE 2009/05/05:

It was working just fine. The microcode_amd.bin file contains more than one microcode patch, and it’s just an “eccentricity” of the microcode.ko module that it prints a warning about the mismatch.