Did you know that you’re probably not allowed to make backups of your computer? It’s true, if you believe in the legal fiction known as “End User License Agreements” (or EULAs), which are those annoyingly long contracts where you have to click “I Agree” before you’re allowed to install some program or another.

For example, here’s a snippet of the Adobe Integrated Runtime (AIR) End User License Agreement:

2.3 Backup Copy. You may make one backup copy of the Software, provided your backup copy is not installed or used on any computer.

Nice, huh? If you install this software, its EULA forbids you from making more than one backup copy. This is a deal-breaker for business which keep multiple backup archives from days, weeks, and months past. According to this agreement, you could hypothetically alter your corporate storage system to ignore each of the files that would be installed, but realistically no one would ever even attempt this.

This is just one more reason to be grateful that EULAs are almost universally believed to be legally unenforcable. However, unless you’re willing to tell a jury that you don’t think you’re bound by such an agreement, remember that every piece of software with a similar license is a potential time bomb. Theoretically, you could be sued just for having it, even if you probably wouldn’t be found liable.

Fans of commercial software often talk about the “impracticality” of Free or Open Source Software, but the alternatives are starting to look a lot worse.

Skip this unless you’re really, really geeky.

Still with us? OK. In the movie “Antitrust”, there’s a screenshot of some code that has a possible Denial Of Service vulnerability:

/* are we doing a GET or just a HEAD */
boolean doingGet;
/* beginning of file name */
int index;
if (buf[0] == (byte)'G' &&
    buf[1] == (byte)'E' &&
    buf[2] == (byte)'T' &&
    buf[3] == (byte)' ') {
    doingGet = true;
    index = 4;
} else if (buf[0] == (byte)'H' &&
           buf[1] == (byte)'E' &&
           buf[2] == (byte)'A' &&
           buf[3] == (byte)'D' &&
           buf[4] == (byte)' ') {
    doingGet = false;
    index = 5;
} else {
    /* we don't support this method */
    ps.print("HTTP/1.0 " + HTTP_BAD_METHOD +
               " unsupported method type: ");
    ps.write(buf, 0, 5);
    ps.write(EOL);
    ps.flush();
    s.close();
    return;
}

Because I can’t resist such things, I paused the movie to read over the code. Now, I’m assuming this is Java instead of C++ because “boolean” wasn’t spelled “bool”, although I’m not sure why they’d be using Java for performance critical code. Anyway. See the ps.write(buf,0,5); line near the end? Well, “buf” is presumably the string that the client sent to the server. If the client is broken (or malicious) enough to misspell “GET” and “HEAD”, then the server politely tries to tell the client what it did wrong by sending “buf”’s value back.

Which brings us to the hack. If “buf” is less than five characters long, then that “ps.write” line will attempt to read past the end of “buf”. If the calling function doesn’t handle index error exceptions, boom! The service crashes: Denial Of Service. Note that this is still better than the C++ equivalent, which would write the contents of memory immediately following the end of “buf” back to the client.

No, I’m not exactly good at sitting back and watching movies.

From the manual of an Asus Eee PC:

The solid-state disk drive’s head retracts when the power is turned OFF to prevent scratching of the solid-state disk drive surface during transport.

I think someone got a little zealous with the find-and-replace.

I was about halfway through a game called “Final Fantasy XII: Revenant Wings” on my Nintendo DS. I was having a great time and loving it until a stupid bug wiped out all the work I’d put in and made me start over.

When I was in the middle of a particularly involved battle, the red “low battery” warning light came on, so as soon as I finished I tried to save my game. Big mistake. The DS used up its remaining power during that instant and turned itself off. When I plugged it into the charger and turned it back on, I got a message saying that my game file was corrupt and had been deleted.

OK, in retrospect, I should have plugged my DS into the charger before I tried to save my game. Still, it should be impossible to destroy your old information by writing a new version of it. That’s just good design. Unfortunately, FFXII doesn’t have a good design. See, the problem is that FFXII saves its game by writing over the pre-existing save file. Since the power died during that write, the results were half old game and half new game. Hence corrupt. Hence deleted. Here’s how a competent programmer would handle the same situation:

1. Create a new save file and write the information to it.
2. Delete the old file.

See the difference? At no point do the two files get mingled together, and the old file stays valid and ready to use until the new one is completely written. In the absolute worst case of a power failure during the saving process, you’d lose the new information but the old data would still be intact and safe.

I don’t know whether the buggy code was written by Square Enix, or if they were using Nintendo’s built-in game saving method. Regardless, it’s dumb and should be fixed ASAP for all new games.

Right now, as I type this, the Yahoo! Finance page for SCO has a caution sign and the text: “SCOX is deficient and bankrupt.” We’ve all been thinking it for ages, but this is the first time I’ve seen an “official” source say so. Wonder what that’s all about?

Back in my Amiga-using days, I had an email program called YAM. It was excellent and ubiquitous; almost everyone used it. It had three unique features:

• You could configure it to embed small bits of personal information in outgoing emails, such as your birthday.
• When it saw these bits in email that other people sent to you, it could add the information to your address book.
• It had an option to automatically send a “happy birthday” email to everyone in your address book on their birthday.

I was active on a lot of mailing lists, so my address book was pretty full with people I’d hardly met. I sent them happy birthday emails each year, and on my birthday, it was fun to get flooded with a few hundred little messages from well-wishers I didn’t know except maybe from some obscure discussion group.

I had the sad realization a few days ago that for the first time ever since I started using YAM, I didn’t receive a single email from it this year. Not one of my old friends still does this. While it’s not very big in the scheme of this, it still marks the sad end to a happy era.

So, I forgot my root password. For non-technical types, that’s pretty much the key to the kingdom when you need to get full access to a computer, or install new software, or to make backups, or to fix something in an emergency. I use this little program called “sudo” all the time that lets you do most of the same things except with your own password. I guess it’d been so long since I’d actually needed that root password that it just slipped my mind. Still, I felt pretty dumb and resigned myself to coming up with a new one and resetting it on all the computers I use.

So, this morning something came up where I really needed that password, and without thinking I picked up a keyboard and mashed it out. It worked. “Oh joy,” I though. “I’ll just do it again and pay attention to what I’m typing.” Except that try as I might, I just can’t type that password if I’m consciously thinking about it.

This has not improved my outlook on an upcoming birthday in the slightest.

In our household, a baby just ain’t a baby without an appropriately geeky birth announcement. And since Nick is mostly functional — I mean, he can’t exactly type yet — this one is in Lisp. Share and enjoy!

; This program forks().  That should be plenty for a few years' entertainment
; Copyright (C) 2007 Kirk & Jennifer Strauser

; This program is free software: you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation, either version 3 of the License, or
; (at your option) any later version.

; However, the output of this particular instance shall remain
; exclusively licensed to the authors for a period of up to eighteen
; years.

; $Id: baby.lisp 4 2007-09-05 23:18:12Z kirk $


(require :sb-posix)

(defvar *birthtime* (encode-universal-time 0 20 1 1 9 2007))

(defvar *age* (- (get-universal-time) *birthtime*))

(defun hello ()
  (format t "Hello, world!  My name is Nicholas Arthur Strauser and this is ~
my ~:r day!~%" (ceiling (/ *age* 86400))))

(defun labor ()
  (cond
   ((zerop (sb-posix:fork)) (format t "Ouch!~%"))
   (t (hello))))

(defun wait ()
  (cond
   ((< *age* 0)
    (sleep (- *age*))
    (setf *age* 0)
    (labor))
   (t (hello))))

(wait)

So, you’ve made a survival kit to keep you alive until the good guys come to rescue you. Well, now you’re starting life over in a new place. These are some of the things you might want to bring along.

References

• <ask.slashdot.org/comments….>

How To Carry It

Electronically

Our primary goal is to make our data as easy to access as possible. This is critically important when you don’t know what kind of machine you may have to use to access your data. You might have a beautiful Mac or Unix workstation at home, but if you were at home and could use your computer, then the rest of this would be pointless. Regardless of what you normally use, expect to be using a Windows box to access it.

First, I highly recommend that you combine your files into a single Zip file. That’s because it’s much easier to manage one file than 100.

Second, and this is critically important, use an encryption program to put as password on the zip file! You’re going to be putting a lot of sensitive information in there, so don’t leave it out for any twit to find if you misplace your copy. I highly, highly recommend GNU Privacy Guard, or GPG. A package of it for Windows is available from http://www.gpg4win.org. Under no circumstances should you trust the lame “encryption” (bah!) that comes with some storage media like USB keychain drives, or such as is built into WinZip. I mean it! Use a stand-alone encryption program.

Don’t forget to put a copy of the installer on your backup media so that you’ll be able to unlock your data when you need it!

Third — and this is very important — create the zip file on your computer’s hard drive, then encrypt it, and finally move the encrypted file onto your backup media. You should never copy the unencrypted data onto that media! Even if you delete it afterward, it may be possible to recover the information.

By the same token, don’t decrypt the zipfile onto your backup media. Copy it onto the hard drive of the computer you’re using to access it, then decrypt it and unzip it from there. Of course, if you’re using a very public computer such as a rental at an Internet cafe, then that may actually be the worse option. Trust your own judgment, and let rampant paranoia be your guide.

Physically

A floppy ain’t gonna cut it. Your encrypted zipfile will probably be much larger than will fit on a floppy disk, unless your life is so simple that this is just an academic exercise. Your four main options, in the order I’d recommend them, are:

1. USB “keychain” drive
   • Pros: they’re durable and can be reused thousands of times. They’re also much smaller than a CD-R.
   • Cons: fewer computers have USB slots than CD-ROM drives, although that’s changing as old machines are replaced — almost all new computers have them.
2. CD-R
   • Pros: blank CD-Rs are cheap, most people have a CD burner (so you probably already have the equipment to make one), and almost every computer has a CD-ROM device to read it. Also, CD-Rs can hold a relatively huge amount of data for pennies.
   • Cons: every time you update your data, you have to throw away the old copy or risk packing away the wrong one. CD-Rs are relatively fragile; one fat scratch and your data is lost.
3. DVD-R
   • Same pros and cons as CD-R, except they hold much more data but are not as widely available as USB slots.
4. Free webmail account (Yahoo! Mail, Gmail, Hotmail, etc.)
   • Pros: access your data from any computer with Internet access. No physical media to lose or destroy.
   • Cons: it can take a long time to store or retrieve your data. Not every computer has Internet access. Your files may be larger than your webmail account can hold. If your webmail company is also destroyed in the disaster, you’re out of luck.

Remember, don’t forget to store a copy of the encryption program you’re using along with the encrypted data itself! Although you can always download another copy off the Internet, that may be inconvenient (especially if you don’t remember what it’s called because you just watched your house burn down and you’re under extreme duress).

Also, nothing says you can’t use more than one option. Just don’t forget to update all of them whenever you add more information.

Whichever you choose, it’s not a bad idea to store any physical media with your regular survival kit. If disaster strikes, you’re more likely to remember to grab your knife and matches than a CD-R or keychain drive.

The List

Store small amounts of information in a text file using an editor like Notepad (on Windows). Do not store it in a Word document! Believe it or not, many computers don’t have an office suite installed on them, and you’d be seriously limiting your access options at a time when you can least afford it.

When scanning documents, set the resolution to at least 125DPI (200 is preferable); greyscale (instead of color) is fine and will use less space). Use at least 300 for photos. Don’t just blindly turn your scanner to its highest setting, though, or you’ll never get all of your documents to fit onto your media.

• Employment
  • Current resume
  • Examples of your work
  • High school and/or college diplomas
  • Letters of recommendation
  • References
• Financial
  • Bank/investment accounts
  • Credit card numbers and expiration dates
  • Loan accounts
  • Insurance policy numbers
  • Contact numbers for all of the companies above!
• Identification
  • Baptism/dedication certificates
  • Birth certificates
  • Driver’s license
  • Family photos (also important for morale!)
  • Fingerprints
  • Marriage certificate
  • Passport
  • Tax returns
  • Voice recordings
• Medical
  • Dental records
  • Disease records
  • Immunization records
  • X-rays
• Property
  • Deeds and titles
  • Wills
• Contact information for lots of friends and relatives, preferably spread over a large geographical area so that they’re not all affected by the same disaster you’re fleeing

Summary

That list is pretty long and odds are you’ll never need it. However, if you do, won’t you wish you’d taken the time to get all this information together? Once you’ve managed to gather it, maintenance should be a snap — just make a new zip archive, encrypt it, and replace your old copy with the new one.

Just remember the basics:

• Pick one or two of the most durable media that can hold all of your information.
• Don’t trust the built in Zip encryption.
• Don’t trust the built-in USB keychain drive encryption.
• Don’t ever put your unencrypted data onto your backup media unless you have to.
• Include an (unencrypted) copy of your encryption program’s installer, or a standalone version that can be run directly from your storage media.
• Also include a copy of WinZip or another file extraction utility. Older versions of Windows don’t have that functionality built in.
• Keep current!

If you do happen to be affected by a local disaster, this information could be incredibly useful. Think about how impressed an interviewer would be to find out that you brought your resume and work samples with you. Imagine how glad the police would be to get a high-quality picture of missing family members. You buy insurance for your house and cars, right? Think of this as cheap insurance for your way of life.

We bought a Western Digital external hard drive for Jen’s computer while we were in Omaha. I hooked it up when we got home and it was dead on arrival. I called for an RMA (“return material authorization” — basically permission to return it to the manufacturer) and got the replacement a few days later. Unfortunately, they didn’t include a pre-paid shipping label to return the defective part, and the customer service guy wasn’t too keen on giving me one. I wasn’t asking for anything unreasonable or that they could justifiably deny, and here’s how I got one anyway:

CS guy: It’s not our policy to give out shipping labels. It’s the customer’s responsibility to pay for shipping.

Me: It’s not this customer’s policy to pay for shipping products that were dead on arrival.

CS guy: I see your point, but that’s not something we normally do.

Me: OK, but I’d sure appreciate it. I mean, I did you a favor by calling you instead of returning this to the store. I didn’t know I’d have to pay for it.

CS guy: Well, we don’t do a very good job of telling you that on our website. I can ask my supervisor, but I don’t think he’ll do it.

Me: I’ll hold.

[5 minutes go by]

CS guy: Sir, this isn’t something we do, but since these are special circumstances, we’ll do it just this one time. You’ll get it within a week.

Me: Thanks! Oh, and can you extend my deadline for returning the broken one by a few days since I don’t have the shipping label yet?

CS guy: (sighs) Yeah, OK. You can have an extra 10 days.

Note two important things: first, I was polite; second, I was assertive. Failure on either of those would have wrecked the whole deal.