AIs will be "born" as whatever they're programmed to be.

Humans are born with a natural predisposition to see actions as the result of a human-like being, with a stronger prejudice toward more-similar beings. That's wholly unrelated to whether such actions actually are a God's will, but it's how we are built. Similarly, a sufficiently-advanced AI could have preprogrammed knowledge that it was built be humans, or it could be left as a blank slate to form its own conclusions about the world. If we are to play the role of God, we can decide what our master plan is for our creations.

Then you've created an AI with prejudice, not emotion. Emotion is a fluid thing, as the result of several competing motivations, but that's unrelated to faith.

Faith is a free choice with a conscious acknowledgement of doubt. I choose to believe in the absence of a God, knowing that there's a chance I'm incorrect. Other people choose to believe in one or more deities, knowing there's a chance they are incorrect. Certain other folks have been born into a society that does not permit any other choice but to believe what society demands, so the choice may not necessarily be a free one.

For a robot to have faith, it must first actually understand what it is considering. It must understand what is observable and what is not, and it must understand what of its belief may be observable.

Free faith is a matter of knowing everything you can, and choosing what you want to think about what is unknowable. Yes, we can create AIs that are not free, but I don't see much achievement in that.

Many realism-emphasizing prosthetic hands are little more than flexible wires inside a synthetic skin. Controlling the position of the prosthetic fingers means reaching over with the other hand and adjusting them.

In other news, I have used two kinds of solar-powered flashlight. One was a lantern with a battery inside, so a few hours sitting in the sun (like on the bow of a canoe) provided several hours of light that evening. The other was a home-built contraption for getting a bit more light inside a cabin with no utility connections. It was a solar panel attached to a regulator and a few LEDs on a long wire. It didn't do much after the sun went down, but during daylight the cabin's window shortage wasn't as obvious.

I take it you haven't actually ever seen a good prosthetic limb, then... ...or you have, but didn't know it.

As the saying goes, you can fool all of the people some of the time, and that's what prosthetic devices are designed to do. The fellow diner lifting his glass to drink, or the empty hand of a pedestrian walking down the street, or the passenger on the opposite seat on a bus... How often do you actually look at their hands long enough to consider how perfectly their skin color matches your expectations? Do you interact enough with them to notice how their skin folds?

Common situations like that are where a more obvious skin color brings even more staring, questions, prejudice, and pity. Current skin doesn't work well enough to fool someone who's looking, but for most common occurrences, it's close enough to be ignored, and that's the desired reaction. Silver or black will have every child (and many adults) pointing and staring, which is usually not so desired.

One of the best examples of abuses of patent reform is part of the history of refrigeration.

Refrigeration, and air conditioning as we know it was locked down for over 25 years because the ice industry was gigantic, purchased patents or had them granted (a metal tube with stuff flowing through it that chances phase, for example), which effectively blocked the refrigerator from becoming a household appliance until after World War 1.

There are two items when people mention PGP:

The OpenPGP format.

The PGP implementation applications, like archaic PGP versions, NetPGP, APG, OpenKeyChain, GNU Privacy Guard, Symantec Encryption Desktop, and a number of others.

As far as I know, all the above have their source code available under various licenses, even the Symantec stuff either has, or used to have, its source available for examination.

I do agree that a revamp in some of the OpenPGP implementation programs is direly needed, because as of now, the most usable implementation (IMHO) is Symantec's version, which is a commercial product.

It might be nice to see about breaking the OpenPGP implementation programs up into to parts -- two library frameworks (one for BSD, and one for GPL v3), and the code that accesses the libraries.

As for the OpenPGP format itself, it does need some incremental improvements:

1: Additional encryption and the ability to chain encryption algorithms. This isn't meant to win a bitsize war, but so that if one algorithm like SERPENT gets broken, there is still AES and Twofish. TrueCrypt implements this.

2: Splitting how much you trust a key versus how much you trust a key's owner to sign, introduce, and validate other people's keys, with both of these values exportable. This way, if you are 100% sure you have a key of a cretin, you can pass that along.

3: Newer compression protocols like LZMA2, bzip2, and others, so that data is further shrunk before encryption.

4: An error correction protocol applied after encryption and signing, with a user selectable amount of ECC applied. This way, a signed OpenPGP file that suffers some damage can likely be repaired, and the signature still be valid.

5: Share splitting. This way, a user can select x out of y pieces be required to recover an OpenPGP packet.

However, all and all, the OpenPGP protocol has stood the test of time when it comes to security. Its main strength is that it is not tied to a communications or messaging protocol, so an OpenPGP packet can be sent on a file on a SD card, via E-mail, AIM, SMS, MMS, posted on a newsgroup or forum, or virtually any other means. There are people who bash OpenPGP, but oftentimes, they have their own solution, and have a vested interest in getting people to leave OpenPGP for a closed system.

OpenPGP fills a crucial need. Not just securing data over communications, but protecting data stashed away. Few encryption protocols can secure both data at rest, and data in motion.

There are also different keyservers. For example, Symantec has its own for its commercial PGP Desktop.

Then there is the need for a key for a transaction. For example, when helping a client out, he already had my key's fingerprint and ID, so there would be no need to publish that for an interchange that was just between the both of us.

Moxie might have a point... maybe it might be wise for some time to be spent improving the PGP/gpg keyserver network, adding more servers, working on better ways to propagate keys, adding code to defeat bogus keys being added in bulk, and so on.

It also is time to see about getting the OpenPGP into other projects. TrueCrypt and 7Zip come to mind. This way, there isn't an issue of having to use an encrypted keyfile or encrypt the entire archive using gnupg, when sending to multiple people and using their public keys.

The problem is that OpenPGP products fill a need, and adding additional, usable features is hard, other than new algorithms.

However, nothing fills the role OpenPGP does with as much reliability, interoperability, and trust. I can encrypt a message on AIX, sign it on a Solaris box, validate the signature on a FreeBSD box, then decrypt and read the file on a QNX embedded machine.

The problem with people bashing PGP and gnupg is that usually they have their own encryption solution they want to peddle. There isn't anything wrong with that... but it is in their interest to belittle the competition, and the one thing OpenPGP (PGP, GPG, NetPGP, etc.) has going for it, is that it is not tied to a single messaging platform. I can sign and send messages on E-mail, decode a message via FB PM, forward the message via AIM, or just send someone a small file via MMS.

This doesn't mean that OpenPGP utilities are "finished." There is a lot of code that can be cleaned up, UI tweaks, work on better WoT tools, new types of keyservers [1]. However, it just seems that people want to sell their own encryption solution, so OpenPGP at best winds up neglected.

[1]: The old style keyserver where keys can't be deleted, just revoked is the best. However, what would be a nice extension to the OpenPGP protocol is a date a private key expires off of keyservers. This is different from when the actual key expires (since one might want the key on keyservers a while longer so it can be used for validation), but this would help with long since outdated keys.

Bingo. Where I live, having more than four sex toys is an "obscenity" state jail felony as per Texas penal codes. So, they are sold as "teaching devices", "medical mockups", or other items.

This is a fight that doesn't need to be dealt with. Just call it a CNC mill, which is designed for fabricating automotive parts. Hoppes calls their #9 product, "lubricating oil", instead of "gun oil." Might as well not have to deal with a wedge issue when it comes to business if one doesn't have to.

The problem is that this employee data, which would be innocuous in the hands of a company, can easily leave the premises. e-Discovery and fishing expeditions are common, and that info can wind up in the hands of someone completely irrelevant.

Of course, there are always the criminal organizations who would love that info. They find that Joe Ducato is out on a long haul... grab his address, sell the info to a local gang, and they clean his home out. This hasn't been the case yet, but as time progresses and if the economy sours further, it wouldn't be surprising to have your local gangbangers swing deals with overseas organizations to buy dumps of potential victims and when their places will be empty. Right now, crime is relatively low, but that can easily swing up due to economic factors.

My philosophy is to use the least amount of data needed, and if has to be obtained, it be decentralized (for example, the AD servers are separate from the HID badge locks, which are separate from Exchange, which is separate from the CCTV room). If the data isn't present, it can't be slurped off overseas and sold.

I live in Austin. If you can get access to the north/south backbone and the hike/bike trails, it isn't too bad. However, get on roads past that... and things get real dicey, real quick, mainly due to the fact that Austin is at a low boil when it comes to road rage, combined with no significant road improvements (other than toll roads) since 1995.

What type of bike you take is also important. If you are on a bus line to and from UT, don't even bother to assume that there will be a slot free on the bike rack at the front of the bus (people will get into fistfights over these). Grab your Brompton and just pack your two wheels with you.

If you are lucky enough to be able to go on and off the core bicycling corridor, it is wise to use PitLocks for the commute bike so wheels, tires, the fork, the seat, and other items don't disappear. It also is wise (assuming with permission) to leave a security chain at the work rack, and carry a U-lock on the bike. This way at work, the bike is secured by two locks [1]. Of course, an angle grinder will make short work of most sturdy locks... but that is what insurance is for.

[1]: I am partial to Kryptonite's high end locks, but Abus is also good. Both resist even expert picking (not pick-proof, but resistant, which is important.)

Ideally, it should do both. One device would have an extremely large amount of bandwidth to play with if in range of the tower, but as more devices get handed off to the tower, there is less bandwidth per device, but all devices get some level of service until a threshold is reached where the tower cannot accept any more items, where even EDGE or GPRS speed cannot be maintained. This is especially important at sporting events or SXSW where there are tens to hundreds of thousands of people in one space. Assuming the tower has terabits of bandwidth available, it should at least provide 3G coverage, decent enough for people to pop selfies and upload them or tweet about how badly the band on stage sucks.

Usually purchase speed is in this order:

1: Debit card. (user swipes card, enters PIN, done.)
2: Credit card. (user swipes card, signs, done.)
3: Cash.
4: Checks.

From what I've seen at stores, people fumbling for their phones at stores is actually slower than the coupon-clipper with the checkbook.

If Google's mechanism goes via credit cards like Apple Pay, it would be useful, should I lose my wallet, as a backup mechanism. However, if it is ACH based like CurrenC... then I would avoid it at all costs, since all it takes is one bad transaction, and I'm cleaned out with no recourse.

It isn't cheap, but there are ways to use 3D printed parts to make "real" parts. For example, with a dissolvable filament, one can print out an intricate part, put it into sand, plaster, or one's preferred moldmaking substance (making sure you have a hole to pour in, and a vent hole), pour limonene in to get rid of the filament, then pour molten plastic or one's metal alloy of choice. Let cool, then separate (or break apart) the mold pieces. The result is a usable part made out of a material that is up to task.

It might be a part just may need improving. The turbo resonator on Mercedes Sprinter T1N models is one example. The original part was OK, but an aftermarket part would completely fix glitches with the item.

Another item might be RV door handles. There was a batch recalled that had breakage issues. If someone scanned the pieces and made identical items, except of a very tough Iconel, the same door handle would easily outlive the RV.

Right now, 3D printing is plateauing, because there is only so much one can do with plastic. However, if sintering, stereolithography, and other items which work with metal or ceramic become inexpensive, this can mean a lot of useful items.

My worry is that we start seeing DRM mandated for 3D printers. All it would take is having the print controller refuse to print any design unless it was signed with an approval certificate, with a number of parties on the Net that are set up to vet that some item isn't a copy of something.

Of course, DRM ends up an arms race, but ultimately, the victory goes to the deepest pockets. (For example, the PS4 and XBox One have yet to even have a dent made with them.)