PCMCIA CF card reader, plus fat formatted CF card, plus USB CF card reader.

Or about a thousand other ways.

Find a compromise between predicting too much of the future and just managing a project by the seat of your pants; get into a rhythm where you check how good your estimations and learn to get better at them.

Of course you can't develop every project this way; I've used Agile and it's worked for me. I've used waterfall and it's worked for me too. You have to try to be sensible; you can't completely wall of other people's need to know when you'll accomplish certain things, nor can you build a solid plan based on pure speculation. You have to have an intelligent responsible way of dealing with future uncertainty, a plan to cut it down to size.

I've even had the good fortune at one point of winning a $750,000 grant to build a system for which no firm requirements had been established. It was kind of an uphill-flowing waterfall: we knew how long it would take us and how much it would cost but we had no firm idea of what we were supposed to build. If that sounds like a recipe for disaster, it was; but my team was *successful* and built a product which was still be used and supported over a decade after the grant finished.

What's missing from many programming estimates is honesty. It's a matter of ethics; you can't take people's money and say maybe someday you'll deliver something useful to them. People don't have unlimited time and money to accomplish all the things that need to be done in the world. It's an honor being entrusted with people's aspirations, and a serious responsibility. It's hard, even nerve-wracking, but you've got to care enough about the impact of your planning on other people to make the effort to do the very best job you can.

And what I've found is that if you do make the effort you can do a surprisingly good job of estimating a project if it's in an area and with technologies you're reasonably familiar with. If you look closely your specific predictions will often be way off, but if you care enough to be brutally honest the pleasant surprises tend to balance out the unpleasant ones.

No purpose if we cease to exist after we die? Is not leaving a better world for our descendants not purpose enough? Is not making life better for our fellow humans not purpose enough? What is it with Christians and their "if humans do not matter for eternity they do not matter at all" sickness?

You are a member of a very unique species: a species able to define a purpose for itself. Nature spent 13,500,000,000 years creating a brain capable of this unique task. Honor the effort and use it. Or, wallow in your nihilist mental squalor. It's up to you.

1. Reddit cannot, in any way, stop you from expressing your opinion. The most they can do is refuse to facilitate said expression.

2. I find it amusing that such a staunch, unyielding proponent of True Free Speech would use such a tremendously wiggly, pro-oversight qualifier as legal In defining what they consider acceptable. Legal implies a level of trust in the state that is entirely at odds with the rest of your post.

1. Reddit cannot, in any way, stop you from expressing your opinion. The most they can do is refuse to facilitate said expression.

2. I find it amusing that such a staunch proponent of True Free Speech would use such a tremendously wiggly, pro-oversight qualifier as legal In defining what they consider acceptable. Legal implies a level of trust in the state that is entirely at odds with the rest of your post.

No, those who want perfect solutions want the impossible. I want a framework that can be improved over time.

What's the goal? With maybe a handful of exceptions, everyone does something that can compromise their security. HTTPS relies on a trust architecture that we're being reminded recently (Superfish, PrivDog) is actually extremely fragile. And yet it's being encouraged to make the job of the average surveillance tool more difficult. It's very much letting The Other Guy(TM) (remember, three caps minimum on the TM'ed stuff) handle security. It has flaws, but it raises the bar.

That's what we need for end-to-end crypto. It can have flaws, but it needs to raise the bar, and be able to keep raising the bar.

As for understanding how it happens, how many people can describe how an RSA key is generated, much less how a proper PRNG produces a suitably random number and then how AES/Blowfish/whatever encrypts the data? Does the average person need to know that? Not really. And even if they did, they don't care, which is why they don't use it now.

Right now, we have options where you can let a CA provide you your TLS certificate (usually 2048-bit and SHA1). If you know what you're doing, you can roll your own with better security. We need something with that flexibility (though I recognize the flaws of that exact model) for end-to-end crypto, too. We need clients that auto-update, that add or deprecate algorithms as they arrive or are broken without the user having to worry about it, and that can provide safe (and revocable) storage for the keys so they survive a catastrophic loss or be deleted with near-absolute certainty if the user wishes. We need common libraries or protocols that can allow new or existing clients to safely implement connections to these services without having to build them from scratch, thereby preserving and encouraging competition.

These don't lead to a perfect system. They lead to a good enough system with room to grow and improve. But I would argue (as I think Moxie does) that what we have now is far from a perfect system because it's too difficult to use.

I cannot even begin to count the number of commenters here who pushed HTML5 as the best way to end, once and for all, those incredibly invasive and annoying Flash ads.

You got exactly what you were asking for.

So long as business is on the web, there will never, ever, ever be a technological "solution" to online advertising. There's simply too much money at stake for that to happen.

First, the complexity of the engine shouldn't matter. You will never get the bulk of users out there to use, or care about, the real power of the engine. They don't want to mess with the engine. The engine should be under the hood, in a black box, whatever engineering metaphor you want. Users just want things that work.

I remember way back when I was at university. There were various absolute rules for good software engineering. The first was that the user should be presented with a must-read manual no longer than one paragraph. Tips and tricks could be more extensive, but that one paragraph was all you needed.

The second was that the user absolutely must not care about how something was implemented. In the case of encryption, I take that to mean, in the case of e-mail, that the engine should not be visible outside of configuration. A supplied key should trigger any behind-the-scenes compatibility mode or necessary configuration to talk to that user. If the keys the user has aren't suitable to correspond with that person, the system should ask if one is needed and tie it to that protocol.

There should be no extra controls in e-mail, except at an advanced user level. If a key exists to correspond with a user, it should be used. If a key exists for inbound e-mail, the key should be applied. The process should be transparent, beyond getting passwords.

Any indexes (particularly if full indexes) should be as secure as the message, good security practices on both will take care of any issues.

Ideally, you want to have the same grades of authentication as for the early certification system, adapted to embed the idea that different people in the web of trust will have done different levels of validation and will be trusted to different degrees. The user should see, but not have to deal with, the level of trust.

Last, GnuPG is probably not the system I'd use. Compatibility cruft needs to be as an optional layer and I'm not confident in implementation.

There should be eight main libraries - public key methods, secret key methods, encryption modes, hashes (which encryption modes will obviously pull from), high level protocols, key store, index store and lacing store. (Lacing is how these are threaded together.) The APIs and ABIs to those libraries should be standardized, so that patching is minimally intrusive and you can exploit the Bazaar approach to get the best mix-n-match.

There should also be a trusted source in the community who can evaluate the code against the various secure and robust programming standards, any utilized theorum provers and the accepted best practices in cryptography. Essentially replicate the sort of work NIST does, but keeping it open and keeping it free of conflict of NSA interest.

Not remotely. He's encouraging good encryption, but calling for some updates (it hasn't significantly changed since the mid-'90s) and a better wrapper. GPG is still largely by geeks, for geeks. I couldn't get my parents to use GPG because they'd dismiss it as too hard, even if one of them is happy to stick it to the man. The suggested minimum settings vary based on where you look and when they were posted.

Example: An RSA key size of 2048 bits is largely considered secure, but NIST recommends 3072 bits for anything that one would want to keep secure into the 2030s. People still often see their e-mail as their private papers and may be concerned over who can read them well past the 2030s. But does that mean they use 3072, or go with the random crypto weblog guy who says to always go with 4096? And why can't I create 8192- or 16384-bit keys like that software claims to over there?

And what to hash to use? Plenty of sites still say MD5, but they were written years ago. Some have updated to SHA1, but others point out weaknesses there. OK, SHA2, then. But then there's SHA256, which must be better, right? (I know SHA256 is a subset of the SHA2 family, but those unfamiliar with crypto will not.)

Until GPG-style crypto becomes relatively automated, it won't be embraced by more than a handful of people. HTTPS is widely used because people don't have to think much about it. This has some downsides for poorly-configured servers and Superfish/Comodo-style backdoors, but browsers and other software help take up the slack by rejecting poor configurations. PGP/GPG were designed to reach near-perfect levels of encryption, but that bar is clearly too high for significant uptake. We should instead be looking for something that encourages end-to-end encryption that is good enough. We can build on if the underlying structure is properly designed, and as people get more accustomed to crypto in their lives, they'll be able to adjust to improvements.

When the majority of communications are relatively well-secured, it makes it far more difficult for a surveillance state to conduct its operations. Perfect security can still be a long-term goal, but we need more realistic goals to encourage uptake in the meantime.

This is only news to those who have had their head in the ground, listening to fox news and government shills.

I've noticed that it seems to be mostly Republicans who are putting up the legalization legislation trial balloons.

(Can't speak about Fox. I don't follow 'em all that much since, during the (especially the last) presidential campaigns, they proved the right-hand side of their claimed "fair and balanced" coverage consisted of flogging the Neocon faction and ignoring or slamming the others - especially the "Liberty" faction and Ron Paul.)

But I haven't checked Thomas.gov to see whether this is accurate, or just an artifact of the media only covering it when a Republican does it, on the "man bites dog IS news" principle.

The Aurora Borealis are not "are an electromagnetic phenomena that can adversely affect ..."

(Putting on my grammar policeman cap, and explicitly not addressing Rob's point...)

I DO wish the author of TFA would correctly use the singular and plural
of "Phenomenon".
  - Phenomenon: One (class of ...)
  - Phenomena: More than one (class of ...)

The Aurora Borealis are a set of related phenomena, involving glows from ionization of various atmospheric elements at different altitudes, various of the Van Allen belts being pumped up with new particles and/or pushed down by magnetic field distortion from solar wind variations, upper-atmosphere currents, ground currents, and I don't know what all else. The author's apparently inconsistent use of the singular and plural makes it difficult to understand what he meant.

The loss of time and effort to figure out whether this is going to cause a problem and then the time and effort to get rid of it.

That loss is obvious not much on a dollar per user basis, but if you add up all those users it's enough to incent Lenovo to do something so scurrilous. That's precisely the situation which class action lawsuits exist to redress, and according to the article that's the kind of lawsuit that has been filed.

The issue isn't whether EULAs are *potentially* enforceable. The question is whether *this* EULA is enforceable.

In general there is no contract unless their is some kind of exchange of "considerations". Typically the consideration is the privilege of using the copyright holder's software. But, if you can show that users don't want to use this software, and that it is installed for the benefit of a third party, there is no exchange of considerations between the end-user and the copyright holder, and therefore no valid contract.

You have no idea what "scientific consensus" means. It does not mean "unassailable truth"; it just indicates where the burden of proof lies.