Such as, for example, upstream developers who might sometimes use libbfd in the process of opening a crash binary submitted in a bug report - so no need to worry about remote code execution, local code execution will do just fine.

$500 million total would fully fund the B612 / Sentinel proposal. I'm not at all sure how far they're getting on private donations to fund it so far - but I'd like to know.

This isn't the problem - detecting these asteriods is a pretty well-understood problem, and the B612 / Sentinel project has a good plan to complete it - but it's not being funded by the Government - it's being run by a non-profit organization. The law is essentially an "unfunded mandate," and I'd guess that there's no particular penalty for not complying with it. However, the Sentinel project likely needs about $30M/year, not $300k/year, but that's still much less than the $200M/year that this chap suggests that NASA would have to spend. I find the disparity pretty credible, as NASA has all the typical government red-tape and home-district stuff to deal with, where the Sentinel project is tightly focused on the objective.

The B612 / Sentinel program (see sentinel.org) proposes to complete the asteroid survey mission at a total cost of under $500 million, and is currently collecting private donations to launch and complete the misson. This proposed cost is a tiny fraction of the $200 million per year that this MIT prof is suggesting is required.

So here's a no-brainer proposal - divert a fraction of the NASA mission cost so that the Sentinel mission can be completed without blowing a giant hole in NASA's bloated budget. The Sentinel mission isn't completely independent of NASA in any case, as it depends on usage of the NASA deep space communication network.

Unfortunately, NASA money would come with giant strings attached to it, and those strings would likely make the Sentinel mission get bloated up toward the NASA mission cost. The Sentinel program is proposing to control costs by for example, having a private company, Ball Aerospace, built the satellite in a manner that they already have expertise to complete. This isn't the way public programs get run - such as making sure it gets built in some powerful politician's home district or include some sexy new technology that will bloat the cost.

both his biggest existential threat and time itself to make it happen by 2013.

Of course, you can stick to Sacagaweas and Anthonys.

You think cash can't be traced - have you noticed a serial number on your Washingtons, Jeffersons, Lincolns, Hamiltons, Jacksons, Grants, and Franklins?

Perhaps you are unaware that a typical salt has historically been much smaller than a password. UNIX systems had a 12-bit salt, BSDi extended to 24 bits and earlier Linux systems had a salt of 48 bits. Only fairly recently has a salt of 128 bits come into use. Salts that were considered adequate in the past, should now be considered trivial.

The point of having a deep-deep-dark-secret password would be to permit the existing infrastructure of textual salted password files, but to augment that with an additional "salt" - thus making validation depend on two factors - the password file as before and second factor of the DDDS password. We've seen many releases of password files, as they seem to be widely distributed from systems that have been broken into. Keeping a second factor elsewhere would complicate the use of purloined password files.

Encrypting the password with a small salt is enough to slow down simple password guessing with rainbow tables. If you make the salt non-trivial, such as encrypting with a 64-bit additional site password, tables wouldn't work. Of course, the same password could have been used to encrypt the entire password file in the first place, but this technique allows the password to be stored in the usual way. You have to keep that additional site password a deep-deep-deep-dark-secret, even more secure than you thought you were keeping your password file. It can't just be included in the source file - or appended to the end of the password file - best if the password verifier reads it from a separate secure location. In that way, 2-factor encoding works for the password data itself.

Good thing no-one could hack or clone your toll transponder or clipper card, right?

http://www.technologyreview.co...

http://www.sfweekly.com/2012-0...
http://www.akit.org/2012/02/ha...

For your proposal, how to do prevent someone from photocopying the "something on a letter or package which identifies me"? For my counterproposal, I suggested (above) that you scribble something unique and take a picture of it (uploading the picture using your account credentials as identification of the package), producing a one-time code that isn't allowed to be reused.

This is pure advertising for the design house. The concept is fanciful and relies on the wacky conceit that we all have packages sitting around the house that we'd like to mark with a personal identifier logo and send without even knowing where it's going to be sent, how much it'll cost to send it, when it'll get there. The design centers on this wooden laser device that is 0.000001% of the system, and I'll bet the vast majority of the work went into making the touchy-feely acoustic guitar paying videos that hype the concept, designed to emulate the advertising of some fruity computer company.

The use case shown in the video, a gift, completely ignores the fact that in order to acquire a gift, I'd have to buy it first, so wouldn't I just have the store send it to my friend? Shouldn't this in be a box that'll handle the rigors of shipment without being damaged, or is it just fine to leave a gift box that any shmoe on the street can open and paw through before my friend opens the now-empty gift box?

Pffffft. Isn't this already built into my phone? Why can't I just scribble something - anything onto a box, take a picture of it with my phone, and have the same effect without the stupid wooden laser thingy that I have to keep charged just in case I have the whim to send a gift to a friend? The answer is that this is a design firm that wants to design stupid little wooden laser thingies and is trying to sell you their services.

Would not recommend running under Wine. Pull the drive to a Windows box, backup to other media, upgrade firmware and reimage or wait for the Linux/DOS version.

Yes, unless you can wait 'tii the end of October for the LInux version (which may be a DOS executable). Alternatively, presumably the firmware upgrade can be done by moving the drive to a Windows box without doing the "Performance Restoration".

That's close. Specifically, I recall another study that really gave me an 'aha' reaction: using PET scanning, scientists found that the response that problem gamblers had to a "Near Win" was virtually identical to their response to a "Win." The upshot is that problem gamblers react to the near wins as if they were a win - they end up thinking they're on a winning streak even when they're losing.

This is bad news for ESPN, that gets several dollars out of every cable subscriber now.