You must work for an oil company :-) The important thing here is energy diversity. With an
all electric drive train, you can be powered from Nuclear, hydro, wind, solar, gas/diesel/biodesel,
coal, alcohol, etc. You also have the long term ability to provide your own power (e.g. solar)
instead of relying large multinational companies to do it for you with many layers of companies
taking a piece of the pie (including stock market shenanigans).

The idea car for me would be a car with an all electric drive-train, batteries for short
trips, and a multifuel small generator in the car. I'm not holding my breath. It would
disrupt too many very rich companies.

> Their leaders might be crazy, but they know the day they strike with nuclear weapons,
> is the last day they are in power and power is all they care about.

Yes, and what if they are about to removed from power, e.g. uprising? What's to stop them from having the
mentality of "if I can't have, no one will".

> AMD has the lead on average FPS, but it's now small enough that Intel wins in a few cases

Not really, Intel does win on a couple cases and is close for some cases.. Most of those are older CPU bound games. For Civ 5, AMD is close to 100% faster. A lot of the games that I looked at were ~ 40% faster (e.g. starcraft 2). e.g.
        http://www.pcper.com/reviews/Mobile/AMD-Trinity-Mobile-Review-Trying-Cut-Ivy/Performance-Synthetic-3D-Real-World-Gaming
        http://images.anandtech.com/doci/5831/trinity-vs-ivybridge-gaming-new.png

So better gaming perf at a cheaper price.. AMD has a better single chip solution for games. If you want a discrete graphics card for games, better to go with Intel.

> Ivy Bridge and Llano actually ended up 'tied

Yes, but Llano is the *old* AMD processor ;-) Check the reviews for performance of a HD 4000 vs a Trinity.

Assuming we're not including discrete graphics card, if you want gaming performance, AMD wins. If you want video encoding or photo editing performance, Intel wins. For most people who have PCs, it doesn't matter because the CPU and graphics are already fast enough for anything there going to do on it.

Personally, I'm going with an Ivy Bridge, nVidia 680 GTX combo. If I was going for a single chip solution, I would probably go with AMD.

> When it's finalized THEN post it.

I think your missing the point of open development. Discussions like this happen all the time. A lot of proposals never see the light of day or have drastically changed when the source is finally pushed.

> $14 billion and produce 2.2 GW of power (able to power ~1 million homes).

Hmm, what if you put $14,000 worth of solar cells on 1 million homes (or $28k on 1/2 million homes, or ...) So you don't generate as much power. But you generate it at a time when you are using the most power. You don't need to hire and train a bunch of folks to run a reactor, and emergency equipment to handle a disaster. Nor do you need to pay to get rid of the nuclear waste. The day to day costs to run solar has to be tons cheaper than a nuclear reactor.

How close are we to it being more sense to do something like that?

How long until it's, 'if your not actively posting a log of your daily life to Facebook, you might be a terrorist.'?

Exactly! Who are all these people running out to get LTE so they can max out their monthly data allowance in 20 minutes of their very first day using the thing. What are people excited about?

When I got my first smartphone, I noticed my thumb started clicking and got sore when using my smartphone a lot. I changed the way I held it and no more problems.

"Doctor, it hurts when I do this, ..."

This would be much better than have to pay $70 and forced to get everything (i.e. like cable or directv)

o stop supporting enterprise deployments (by rapid release, no bug fixes only)
o start an enterprise working group
o profit! (charge for support)

How much are they willing to compensate me if they lose my data? What, they won't? Don't trust themselves?

Yes, I am aware of that. Your missing my point. I wasn't trying to iterate over
everything that a test plan will cover.

Writing a test plan doesn't ensure you have met any of your requirements or
than even if your requirements are worth a crap to start with.

The point being writing a test plan does not mean you have a good plan on
how to verify your product (from unit test through deployment and maintainance).
That is what's important. If you want write a test plan which references
to requirements, great. Usually required for any contracts anyway.

But it's the plan that is important, not the document. I haven't see a
checklist item yet for a good plan/bad plan. And I've seen many
really bad test plans go by which fulfilled their process checkmark.

> However if you're likely to have millions of people depending on your code, which will
> alwso be modified by other people, then you had better have a good process as well.

A good process means nothing. Understanding why a process wants you to do something
is what's important. Checklists are bad. Making sure the right things get done is what
is important. Writing a test plan isn't important. Making sure you have good test coverage
is important.

I have been writing code professionally for over 20 years now. I have been at a handful of
different companies, and gone through a few handfuls of various processes (2167a was
the first one I had to use coming out of school). I've worked on very large projects and
very small projects.

For small to the small side of medium projects, it comes down to the people
working on the project, period.... In my experience, a standardized process doesn't
effect the success of a project either way. If you have a good project lead, and good people,
you will have a "process" or a somewhat standard way to do things. It doesn't have
to be documented in a formal document. But it will be there even if you don't realize it.

Large projects are a mess. You need a standardize process as painful as it is. One that
allows you to integrate early and often. The first thing you need to realize that the % of
incompetence rises the larger the project. It's easier to hide in a large project. It's easy to
hide in a process that generates a lot of information. You have to identify problem areas
in interfaces, and people, early and often..