Going to a very large church, he began taking photographs and making notes. He spotted a golden telephone on the vestibule wall and was intrigued with a sign, which read ‘Calls: $10,000 a minute.’

Seeking out the pastor he asked about the phone and the sign. The pastor answered that this golden phone is, in fact, a direct line to heaven and if he pays the price he can talk directly to God.

The man thanked the pastor and continued on his way. As he continued to visit churches in Seattle , Dallas, St. Louis, Chicago, Milwaukee, and around the United States, he found more phones, with the same sign, and the same answer from each pastor.

Finally, he arrived in Pennsylvania , upon entering a church in Pittsburgh , Pa .. Behold - he saw the usual golden telephone. But THIS time, the sign read ‘Calls: 35 cents.’

Fascinated, he asked to talk to the pastor, ‘Reverend, I have been in cities all across the country and in each church I have found this golden telephone and have been told it is a direct line to Heaven and that I could talk to God, but in the other churches the cost was $10,000 a minute. Your sign reads only 35 cents a call. Why?’

I love this part ………………………

The pastor, smiling benignly, replied, ‘Son, you’re in Pittsburgh, Pennsylvania home of the Pittsburgh Steelers now…… You’re in God’s Country, It’s a local call.

(American by Birth - A Steelers Fan by the Grace of God.)

GO STEELERS !!!!!!

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:0b:02:d2", NAME="eth0"

These seemed to be silently ignored.

After an emerge --sync; emerge -u world last night, the vmware devices started getting IDs following the highest-numbered eth device. These rules would be added to 70-persistent-net.rules, and on the next boot the devices would move up even higher, causing all network device config settings to be ignored.

I noticed that the new rules added to 70-persistent-net.rules were of the form:

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0"

(ATTRS was replaced with ATTR), which just means the match is done on the specific node rather than checking all of the parents.

After a lot of painful attempts to fix this, I finally found the problem. Apparently the DRIVERS key is unset at this point for the vmxnet driver. I removed that test, so that I have:

SUBSYSTEM=="net", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0"

which now works.

Phew!

Of course, the new machine came with Vista, which actually runs fairly well (the quad-core 2.4 GHz processor may have something to do with that… or it could be the 3 GB of RAM or the SATA RAID hard disks…). I put the drive from the old system in and started moving things over, but I ran into problems trying to delete some old directory trees (particularly the old Cygwin install) due to permission problems.

A bit of poking around on Google led to a useful tip on Tim Sneath’s MSDN blog: Windows Vista Secret #11: Deleting the Undeletable. The short version is:

    takeown /f directory /r /d y
    icacls directory /grant administrators:F /T

Works like a charm. Just use a command prompt with administrator privileges.

So, new (sucky, but best I could do on a moment’s notice) name, new theme, and more tech content (when I get a round tiut, of course).

Installation was pretty painless, the ASUS A8N-SLI mobo has support for 4 SATA drives, and my Antec Sonata case has SATA power connectors (which, interestingly, are about twice the size of the data cable), so I plugged it in, turned the SATA interface on in the BIOS (I tend to disable things I’m not using) and booted into Windows.

XP recognized the new hardware, asked for the nForce4 SATA drivers (the latest of which were already sitting on the IDE drive) and installed them. A quick click through the WD install software and the drive was formatted. I started the WD drive migration tool on the expectedly long process of copying 140 or so GB of data from the old drive to the new and headed to bed. I was a bit suspicious of the tool’s ability to copy everything over while XP was running, but I figured I’d give it a shot and headed to bed.

In the morning the copy was done, so I shut down Windows, removed the IDE drive, and powered back up. The BIOS screens flashed by, then I saw it: “Error Loading Operating System”. Apparently my drive, which was perfectly accessible from a fully booted XP install, was not bootable.

To make a (very) long story short, I tried a lot of things to fix this. I started by using Acronis True Image to reimage the drive without XP running. No luck, so off to Google.

I saw lots of recommendations to do a repair install, which requires a driver floppy to access the SATA drives in this system. Since I don’t have a floppy (and the ultra-modern XP operating system doesn’t seem to think this is possible) I couldn’t use my boot media, so I downloaded a fresh copy of nLite and bundled the drivers into a new, custom install CD (along with SP2, which was already on the system). I tried using the recovery console from this CD (which could access the drive just fine), but no amount of “fixboot” type stuff helped. I tried a repair install and still couldn’t boot. Finally I reformatted the disk and did a new install. It still would not boot.

Then I found a post that recommended changing the disk access mode setting in the BIOS from “Auto” to “Large” (the only other setting…). This changed the boot error message, so I started another clean XP install. This time I made it through the reboot and into the GUI installer, so I shut down, reinstalled the IDE drive, and reimaged (with True Image). Everything is now working beautifully!

This only took about 14 hours for someone with 20+ years of computer experience and a degree in the field. No wonder people pay Best Buy to do this crap!

	V.W.H. Campbell Jr., Post-Gazette A BomBot closes in on a mock improvised explosive device during a demonstration yesterday in Fairmont, W.Va. Click photo for larger image.

Zipping over the pavement on saucer-sized black wheels, the remote-controlled truck at first glance appears to be a souped-up version of a battery-powered sidewalk toy.

But by next week, hundreds of these metal-sheathed, camera-equipped robots will be hitting the ground in Iraq, where U.S. soldiers will use them to destroy lethal improvised explosive devices from a distance.The remote-controlled BomBot, aims to provide U.S. forces with a safer, more cost-effective way to detonate the improvised explosive devices, or IEDs, that increasingly are used by opponents in Iraq and Afghanistan.

The camera-equipped, 20-inch-by-20-inch vehicle works like a miniature dump truck to deliver explosive charges that will detonate IEDs, which have been blamed for the deaths of about 800 U.S. soldiers since the war in Iraq began three years ago.

Soldiers in combat zones will place a 10-pound packet containing C4 explosive in the BomBot’s bed, then use its remote control to steer it to an IED and to dump out the packet. After summoning the BomBot back, its operator detonates the packet and, with it, the IED.

The devices are being built by the West Virginia High Technology Consortium Foundation and its subsidiary, Innovative Response Technologies Inc., at the Interstate 79 Technology Park in Fairmont.

Several other firms and organizations from West Virginia and Pennsylvania also participated in development and construction of the small, light robots intended to replace slower, costlier and more cumbersome devices now in use.

Among them are the National Center for Defense Robotics on the North Side, which funded and managed research and development of the BomBot’s radio controllers, and Nomadio Inc. of Philadelphia, which manufactures the radio system.

“[BomBots] can be rapidly deployed and carried in small vehicles. Many people can be trained to use them,'’ said Brad DeRoos, the foundation’s vice president of research and development. “[They are] going to save lives, there’s no doubt about that.'’

The first shipments of 200 BomBots left the technology park this week and will be followed by 2,300 others commissioned in a $9.6 million contract awarded Jan. 17 by the U.S. Navy. The Navy oversees development of technology for disposing of explosives for all service branches, said Keith M. Moore, program manager of the National Center for Defense Robotics.

Each BomBot costs about $5,000 to assemble, compared to earlier bomb-disposal devices that cost $100,000 or more, Mr. DeRoos said.

Even similar robots considered previously by the military would have cost around $12,000, he said.

Not only were those devices pricey to build, but some of them were themselves destroyed while detonating IEDs, foundation officials said.

The BomBot’s lower price makes it more expendable and, at 15 pounds, it can be carried more easily than larger, heavier disposal devices that must be hauled on a trailer or in a Humvee, they said.

“Insurgents are taking out [bomb-disposal] devices to slow future responses,'’ Mr. DeRoos said. “These are rapidly replaceable and not as expensive to the military.'’

But the BomBot’s chief benefit, officials said, is the protection it provides for soldiers who can use it to detonate IEDs from up to 1,640 feet away. That is particularly satisfying to James L. Estep, foundation president and chief executive officer, whose 21-year-old son, Adam, is serving in Iraq and recently lost a friend in an IED blast.

“As somebody who thinks about this issue virtually every minute of the day, clearly this is a top priority for me,'’ Mr. Estep said.

BomBots are not built from scratch but are modifications of commercially available remote-controlled monster trucks that are intended for adults to race and sell for $350 to $500.

Workers in the Fairmont plant first perform computer tests on each vehicle to ensure the gears, engine and batteries work properly.

Workers replace the original wheels with larger, tougher versions and swap out the radio for a tamper- and jam-resistant model that responds only to its operator’s hand-held controller. They upgrade the truck’s transmission and clutch and modify its springs so that it can reach speeds of up to 35 mph and carry a 10-pound load.

Then they add an antenna, a dump-truck bed, a flashlight-sized camera that provides a 360-degree view and conduct more tests. Military officials visit the plant weekly and conduct their own quality tests as well.

The foundation and its partners in the project first developed and built prototypes, which were critiqued by soldiers who tested them in the heat and sand of Iraq, said Bhana Grover of Nomadio Inc.

“Based on those tests, they made the decision to go to this [version],” she said.

“We listened to the users.”

---

Robots built in W.Va. going to Iraq to detonate bombs
(Pittsburgh Post-Gazette, Friday, April 21, 2006).

V.W.H. Campbell Jr., Pittsburgh Post-Gazette Click photo for larger image.

BomBot during the testing phase (Credit: WVHTC) Click photo for larger image.

• BomBots going to war, (The Charleston Gazette, April 21, 2006)
• WVHTC Foundation Captures Robotics Contract From U.S. Navy, (WVHTC news release, January 17, 2006)
• BomBots will save many lives, (Roland Piquepaille’s Technology Trends)

Use the link above or click the banner in the sidebar to let them know you hear it here!

When I get some pictures of these things in-theatre I’ll post them here.