It’s amazingly useful, and so much more intuitive than the standard library equivalents (os.path, etc.). If you’re like me, and you never got the hang of iteration or recursion in bash scripting, this module is for you.

I’m using it to iterate over all directories on the server with a ‘preproc.log’ file in them and collecting information about some of the files within.

import time
import path

DAY = 24 * 3600 # seconds
NOW = time.time()



globs = (("run*_raw+orig.BRIK", 21), # glob, max age
         ("p*_auto+tlrc.BRIK", 28))

def age(f):
    return int(NOW - f.atime) / DAY

p = path.path("/home")
for preproc_file in p.walkfiles("preproc.log"):
    p_dir = preproc_file.parent
    for glob_pattern, max_age in globs:
        for f in p_dir.files(glob_pattern):
            if f.islink():
                # ignore symlinks
                continue
            elif age(f) > max_age:
                print f.size, f
 

#!/bin/sh

HOSTNAME=`hostname`
sudo cat /etc/ssh/ssh_host_dsa_key > ws_keys/ssh_host_dsa_key.${HOSTNAME}
sudo cat /etc/ssh/ssh_host_dsa_key.pub > ws_keys/ssh_host_dsa_key.pub.${HOSTNAME}
sudo cat /etc/ssh/ssh_host_rsa_key >    ws_keys/ssh_host_rsa_key.${HOSTNAME}
sudo cat /etc/ssh/ssh_host_rsa_key.pub > ws_keys/ssh_host_rsa_key.pub.${HOSTNAME}

chmod go-r ws_keys/*.${HOSTNAME}

The solution I’ve come up with is to use a caretaker pattern, which means a program on the server side which creates, unlocks, and re-locks the appropriate directory. The workstation prepares the new data and then calls out (via ssh and sudo) to the caretaker, which prepares the new directory. The data is copied over, and then the caretaker re-locks the directory.

Check out that curve! Woo! I’ve got your logarithm right here!

File /dev/dpti17 Could Not Be Opened

I haven’t recompiled my raidutils yet, hoping for a swift resolution of the bug.

I settled on whetstones, a benchmark with gravitas. Also, it can measure double-precision floating-point arithmetic, the same kind of operations most of the computing we’re doing does do. My new machine has 31% fewer bogomips than my previous champ, but can do 50% more whetstones.

I’m just running the old Debian i386 on this machine, since the speed boost is substantial, even without re-compiling everything over to 64 bits. I’ve installed debian-amd64 on a spare partition, and I’ll play with it a little when I get a chance. Rebuilding everything and setting up a special distribution system for the x86_64 stuff is a bit of a pain, though. I might wait until I’ve got another 64-bit machine before I go too far with it. I don’t think the man-hours saved by moving up to 64-bit exceed the number of hairs I’d pull out of my head doing it, figuratively speaking.

Dell Precision Workstation 350 has a problem when running Linux kernels in the 2.6.x series with the keyboard and busmice. If you boot them up without touching a key (say in GRUB, for instance) you’ll get a message like i8042.c: Can't read CTR while initializing i8042 in your dmesgs.

This makes the keyboard and mouse not respond. If, while trying to debug this problem, you touch a key sometime between POST and when the kernel tries to initialize the i8042, you won’t have this problem.

One workaround is to touch a key between POST and initialization every time the machine boots. Another workaround is to add acpi=off to your kernel bootup arguments, say in GRUB or LILO. I understand that you could also pass i8042.noacpi=1, according to the linux-kernel mailing list — but I haven’t tried this.

This is very annoying.

Also, this does not seem to affect Dell Precision Workstations 360.

It did not. Now, I’m left with the conclusion that I’m facing a situation like that described in Adaptec knowledge base article #2328, which tells me I need to backup my RAID, format all the drives, rebuild the array, and restore the data from backup. Does anyone have 1.4 terabytes of storage they can lend me? Next year, this will not be a problem, because we’ll all be running around with USB keychains with that much space. Right now, though, it’s problematic.