I had a perfectly good reason for doing it this way…

declare id
function hexhex () {
  printf -v id %06X 0x$1
}

Reading the emerging story about the T-Mobile/Sidekick data loss, I was surprised to discover that this guy isn’t working there. In fact, he’s not even on the West Coast any more, which makes me feel better about all my data.

I have some friends at what used to be Danger, and I know they’ve been working frantically at damage control, but I can only see blood on the walls in this one. Some people screwed up bigtime, years ago, both procedurally and technically, and if the original culprits are gone, their replacements will get axed for not spotting, and removing, the vulnerabilities.

Microsoft can afford the financial hit it’s going to take from this, but the PR hit is devastating. Any product line that says “trust us with your data” is in big trouble.

[why, yes, I did just update and verify my offsite backups; why do you ask?]

SQL interface to Perforce.

It’s been around for quite a while, but I’d never noticed it; most of my data-mining has been at levels that can be satisfied with the usual command-line interface. It will come in handy for my branch-to-branch bugfix-integration report, though.

I don’t want a database guru. I want a database ogre, who lives in a dank, dark cave lined with the bones of developers who think they can write their own queries and release them to Production.

During my latest round of load-testing, I discovered that one particular client-driven query degrades rather seriously under load. As in, fifteen minutes to use a unique device ID to look up the matching unique customer ID and a single string related to RMA status. Part of the problem was that the dev was looking in the wrong place, but the main problem was that he didn’t understand the data, so the query was written in a way guaranteed to maximize search time. (rant about poor schema design saved for another day…)

I am a SQL caveman. My formal training in database technology began and ended with a single COBOL class in the mid-Eighties. I rewrote the query and dropped the time to 0.062 seconds under the same heavy load.

Four orders of magnitude? Time to feed another dev to the ogre!

(and, yes, the checkin comment attached to this query begins “optimized the sql query for …”. The sad thing is that, relatively speaking, this is a true statement; his previous code was worse)

In the past seven hours, I have received 490 pieces of spam. One made it to my inbox. One almost made it to my inbox. The rest were caught by SpamSieve, with no false positives.

So, yes, I’m pretty sure that the catchall mailbox at jgreely.com is working again. :-)

I moved one of my parked domains to a new account at Pair, the hosting side of domain registrar PairNIC. They offer clean multiple-domain support with catchall mailboxes and sophisticated filtering, secure IMAP and SMTP, and a full range of scripting languages and libraries under FreeBSD. Once I’ve tested everything out with that domain, I’ll move jgreely.com over, as well as the J-E dictionary I’m currently hosting on jgreely.net.

It will be a while before I can resume the blog upgrade work I started a while back, so dotclue.org won’t move to the Pair account any time soon, and neither will my old high-volume picture site (which survives because of bandwidth-throttling firewall rules). All of the non-blog CGI will probably end up on jgreely.net once that domain is migrated off of the flaky old Shuttle sitting in my closet.

#!/bin/bash
cd deferred
find . -type f | split
for i in xa*; do
    for j in $(cat $i); do
        echo -n "$j " #literal tab
        postcat $j | awk  '
            /^From: / {f=$0}
            /^To: / {t=$0}
            /^Subject: / {s=$0}
            END {printf("%s\t%s\t%s\n",f,t,s)}'
    done >> /tmp/jfoo
done

Open in Excel, sort to taste, cleanup as needed, save for later use...

Saved for future reference, since I don’t do it very often…

1. From another admin account, open System Preferences, click Accounts.
2. Control-click the username, select Advanced Options.
3. Change the UID and optionally the GID.
4. From a root shell, chown -R the user's files.
5. If you changed the GID, run:
   dseditgroup -o edit -a $USER -t user $OLDGROUP
6. If you want to add more local groups to match your NFS server, run:
   dseditgroup -o create -r $DESC -i $GID $GROUP

Over on slashdot, someone quotes:

"The study also found that over a third have suffered from sleepless nights or headaches as a result of IT problems at work, while 59 per cent spend between one and 10 hours a week working on IT systems outside normal hours...."

In the modern vernacular, I say “It’s fine, learn to play, noob”.

“Why, when I was a boy, we had to walk to the server room through three feet of snow, uphill both ways! Now get off my lawn!”