Riding a motorcycle gave me a slightly different view the weather and local climate.

I have to pay much more attention to rain forecasts. Because a two-wheeled machine can have traction and stability problems on wet pavement. And because the motorcycle has no roof.

Temperatures also have a different meaning when I'm rolling at 45 miles per hour. (Or 65 mph...) A day that goes from 60° F to 80° F means that I need the windbreaker jacket for the morning ride, and the vented jacket for the evening ride. However, a day that goes from 70° F to 90° F doesn't change the ride as much.

On many nights, I can feel the change in humidity when I descend into a river valley. Sometimes it's warm and moist; sometimes it's cool and clammy.

Last night, the temperature dropped from upper-70s to lower-60s. Which means that today, I may drive my car instead of ride my motorcycle.

This summer has been cool, which has decreased my desire to ride as much as possible. But I also have a car that is better than the car I had last year. So maybe I enjoy driving a little more, also.


Computer Problems

I've done quite a bit of computer repair in my time. I'm not a professional computer repairman. (There's more money in writing programs than in repairing hardware.)

Most of that has been software repair. Uninstall bad programs, upgrade programs, pull backup copies of pictures/documents, fix OS installs, clean out registries, etc.

Other things have been hardware upgrades. New displays, new network cards, additional hard-disk drives, replacement/upgrade of optical drives, etc.

Very few times have I needed to replace broken hardware.

Once, the broken hardware was a light bulb. A miniature fluorescent bulb that provided a backlight to an LCD display on a laptop. That fix was challenging, mainly because the laptop in question was not easy to disassemble.

My most recent repair on my own machine was a replacement of a faulty Hard Disc Drive. That drive had begun making strange noises during read/write access. And I sometimes got errors when I executed commands like "svn status" on the subversion repository stored on that drive.

Some time ago, I helped my parents recover a Hard Disc that was failing slowly. It wasn't making funny  noises. It was simply not saving important data in one location. This failure convinced the Windows bootloader that the drive didn't contain a valid filesystem.*

This hardware failure wasn't drive-destroying...but there was no way to restore the copy of NTFS on that drive and keep all the old files. And my parents wanted to extract all the Documents and locally-stored email that had been on that drive.

So I (with some trepidation) began searching for "file system recovery" tools online.

I rapidly discovered that if I could produce an image of the data on that HDD, I could pull all sorts of stuff from it. Including the files that my parents wanted. And deleted files, fragments of deleted files, data stored in the swap file, data stored in the Recycle Bin, etc.**

Among these files/deleted-files/fragments-of-files were lots of emails.

The entire process took me about 12 hours. However, these hours were spread across evenings of several weeks.

This is one reason why, when I read stories like this, I am not surprised. There are several different ways for an HDD to fail. Unless the failure involves destruction of the disc platters inside the HDD metal box, then most of the data can usually be restored/recovered.

If the IT team at the IRS didn't maintain central backups of internal emails, they should still have been able to recover most of those emails from a faulty HDD.

* The deep technical details: one of the data-storage sectors on the disc had gone bad. It could be read from, but all write operations would fail.
This copy of Windows was installed on an NTFS partition. Usually, NTFS can recover from this kind of failure. When the problem is detected during a write, Windows/NTFS can re-send the data to the drive with instructions to save it elsewhere. In many cases, this can happen without Windows telling the user!
However, this particular bad sector involved one of three redundant copies of the Master File Table. Windows and NTFS kept on trying to fix the bad MFT without moving it. The write operation would fail. Windows would check the attempted fix, discover the that the fix didn't succeed, and halt the Startup process. Then the user would see a message about a Startup failure, with a recommendation to try again.
Trying again produced the same result.

** Another aside: at one time, I worked for a company that performed contract work for DARPA, the Advanced Research agency of the US Dept. of Defense.
Several employees at the company had to get Security Clearance, and the company had to follow US DoD procedures for handling Classified data.
The US DoD-approved process for clearing Classified data from an Hard Disc Drive involves a custom program that will attempt to overwrite every bit of every byte of every sector on the HDD. Then the progam repeats this process four more times.
This knowledge came in handy. It also clarified for me that a determined attacker (or IT support person who wishes to comply with legal requirements for data retention) can extract most old data from a Hard Disc. Unless the disc is (a) put through the above process for cleaning out old data, or (b) mechanically disassembled and the components physically destroyed.


Camping Trip

This past weekend was swallowed up by a camping trip.

The church that I am a part of had organized the camping trip.

Good times, even if I didn't do as much out-doors stuff as I originally hoped to.

I hung around at campfire with my friends, had a few pleasant conversations during afternoon and evening. Awoke to a cold morning with mist hovering over the lake. Saw some sandhill cranes flying and simming on the lake. Watched some camp-site volleyball, rode a bicycle around. Did some cooking over a campfire.

At the culmination of the trip, we had an outdoor church service and a baptism ceremony in the lake.

The weekend was good, and restful.

I'm happy.


Correlation may not be Causation

...but correlation may be standing the corner, flirtatiously winking. And saying sweetly, 'yes, it does look like I caused that.'

Donald Sensing has linked to an article and chart titled Marriage Makes Us Stronger.

The chart shows that the kind of people who marry tend to be the kind of people who do better at many things in life.

However, it doesn't show that marriage is the cause. It only shows that the two effects travel together. (Heck, a successful middle-class life might be the cause of stable marriage...or both might be caused by outside factors.)

Still, if the conclusion is that Government policies which discourage marriage may be bad things...then I can agree. For other reasons.


Computer Hardware replacement

After earlier excitement (and trouble) with a failing hard disk, I ordered a replacement.

The replacement arrived. So I plugged it in, and began copying data onto it.

Five hours later, the first backup copy was in place. As was the first copy of the new SVN repository.

Though now that I think of it, maybe I do want to use GIT instead of SVN...


Statistics: gunshot victims

Referenced by Clayton Cramer (and Dave Hardy), a news story about the kind of people who usually show up in hospitals as gunshot-wound victims:

People hospitalized with a firearm injury are 30 times more likely to return to the hospital with another firearm injury than people hospitalized for other reasons. And they’re 11 times more likely to die from gun violence within the next five years, according to a study commissioned by the Seattle City Council....
It is hypothetically possible that gunshot wounds cause these effects.

It is also possible that gunshot wounds and the other results are all linked to an underlying cause that hasn't been stated.

I suspect that this second possibility is much closer to the truth.


Computer Hardware failures

I lost a lot of data that I had intended to keep.

Confound and blast that infernal computing device! (And the User who deleted a file that he wanted to keep...wait a minute, that is myself.)

To explain, from the beginning:

I've been kind of paranoid about keeping backups of important files. This was made much easier when I discovered that Linux made this fairly easy. As long as I had a place to keep backup files, I could create a cron-job and a script that would generate backup copies.

And the "place to keep backup files" was, usually, a second (or third) hard-disk on my main machine.

Much later, when I decided I wanted to use an older computer as a print-server, it also took on the role of backup-server. Thus, the backup script used the local extra-hard-disk for backups, and copied the backups out to an external machine.

Even later, I discovered the fun and joy of version-management software. This is a custom database for data files. Usually, tools like SubVersion or Git are used by software teams to manage and document the history of changes to software projects.

But I realized that SubVersion could also track a bunch of document files. (Like the spreadsheet I use to manage my finances, or electronic copies of receipts for online purchases, or the other files cluttering the local "Documents" folder on my "/home" partition.)

While I was doing this, I also learned about and purchased a portable, external Hard Disk. So I configured the external drive as the local Backup-plus-home-of-SubVersion repository. And I tweaked a couple of scripts on the aforementioned cron jobs to handle things.

Except I got lazy, and mangled one of the path names. And one script, intended to create a backup "dump" of the history of the SubVersion repository, never worked properly.

Thus, when I began hearing odd noises from the external backup drive, I investigated.

I discovered that the backup "dump" of the SubVersion repository wasn't useful. And I discovered that the partially-failed drive left the SubVersion repository in a state that could not be updated, modified, or fixed.

So I manually pulled the dump. Which was successful at bringing out 90-something-percent of repository history.

And then I tested rebuilding the SubVersion repository from the dump. It appeared to succeed, so I deleted the dump, and attempted to re-create it.

Which was the wrong order of operations...I should have attempted to create another dump file from the restored repository before I deleted a known-mostly-good dump. Because the restored repository failed much earlier in the dump process.

And by deleting the older dump file, I lost most of the history that I had intended to keep.

My backups are still in good order, but I lost a lot of history.

One other thought: if I had used Git instead of SubVersion, the local file system would contain the entire history, as would the repository on the remote drive. Maybe I should switch to Git....