V2 had nowhere near the payload capacity for an early nuclear device. One tonne / 300 kilometers. Compare to more than four tonnes for little boy / fat man.

Also, Japan just didn't have the industrial capacity to wage war any longer-- it's just a question of how costly invasion was going to be. You can't tool up to build V2's and nukes in the face of invasion.

Also, there's the question of how many more times we would have nuked Japan in the meantime. We were about to be producing three per month. Probably would be good to build a stockpile, so maybe drop one every couple of weeks?

> It's also much smaller than Earth and Venus, so the area exposed to the sun (from the sun's point of view) is around 12% of Earth's. So it gets much less heat.
And light.

It's dimmer on Mars because of the inverse square law, not because of Mars being smaller. Mars being smaller doesn't have much of a direct effect on temperature, either.

> The images we see from Mars are not what we would see if we were there - the cameras are adjusted for less light, and exposure pushed up so we can see things clearly.

I think you -severely- underestimate the dynamic range of the eye compared to practical cameras.

For one, the pressures still need to work out that you can move your chest to breathe, if you're just going to wear a mask/helmet.

... Real airliners have fielded automated systems to avoid birds? Nope...

I am a big airplane nerd, have a license and many type ratings for interesting aircraft. I also do a lot of systems engineering. There are not many systems that intervene and take action on behalf of a human. You can find various kinds of fairly-static control loops on aircraft (autopilots, pressurization systems). There's some things that take immediate protective action, like circuit breakers. You can find things like stick-pushers that will apply forward pressure to the stick/yoke after some time of warning of an incipient stall.. You can also find things like envelope protection / more advanced "do what i mean" control laws on Airbus.

But when there's a fire on an airliner, it's almost always the flight crew that pushes the button to discharge the fire bottle. When there's an incipient collision, it's a flight crew who listens to the order from TCAS and decides whether to comply.

The thing is, yes, computers are really good at responding to understood, common failure modes. Aviation accidents have progressed beyond understood, common failure modes to esoteric strange events. This is because we've augmented human ability with CRM, automation of routine things, additional alarms and alarm prioritization, etc, etc, etc. Remaining failure modes exercise the redundancy in unanticipated ways-- like someone taping over (and not removing the tape from) all 27 static ports on the aircraft and the static ports leaking air out but not allowing air in. People are good at problem solving and figuring out what is going on in those types of circumstances. Machines are very bad, currently, at that type of anomaly detection and resolution.

There are times that having a human in the loop means a human does something stupid and kills everyone aboard. E.g. AF447 (though I wonder how well a machine would do, because the Airbus fell out of the more sophisticated control laws to a base level of automation because of the contradictory sensor readings). There are also more times when a human with a high level of systems knowledge and troubleshooting.

Overall, the philosophy is this-- We make the flight crew behave like a machine under ordinary circumstances, with a lot of automation of routine flight and decision support and checklists. When things go wrong and off the scripted checklists, we instruct the flight crew to use the automation if possible (autopilot, etc) and to troubleshoot systematically, to communicate with each other and divide up manual responsibilities, and to effectively question each others decisions while keeping on the problem.

This is what the human factors crowd and the NTSB have decided is the best path for aviation for the foreseeable future. Perhaps you know better? Even Airbus, who is on the leading edge of having the computers do more and more, doesn't go anywhere near as far as you describe.

Substitute $1,000 for all $10,000 in the above post.

No, I think the rules are broken.

The policy justification behind AMT was to force people to pay at least a certain minimum rate of tax on actual income. To catch some of the various tax avoidance strategies, it considers different timing for when gains are actually recognized.

If you have 100,000 stock options for $0.01, and the stock is at $100.00, and you exercise those options-- you now hold stock worth $10,000,000 and paid $10,000. If the stock then goes to 0, you just missed out on $10,000,000 you could have had by selling earlier. You have a $10,000 capital loss. But the IRS will show up saying you owe $2,600,000. But hey, they're generous-- you can apply what you're able to pay against future years' taxes.

On the other hand, if you buy 100,000 shares of stock for $0.01, and then the stock goes to $100.00 and then down to $0.00, you have a $10,000 capital loss.

There's totally fixing the human! Look at what's happened to the commercial aviation accident rate. We improved equipment, procedures, how people get along (cockpit resource management), and found a lot of ways to augment human intelligence and prevent humans from doing the things they're worst at (vigilance tasks). We built things like TCAS that give mandatory commands for humans to follow to avoid fellow aircraft, and envelope protection as last lines of defense.

There's very few accidents... Many of those remaining have failure chains involving flight crew, but humans also save the day/recover from failures of systems and situations and unusual edge cases more often.

The problem is the edge cases.

On one hand, there's the false positives-- the falsely perceived hazards at the end of your route when you need to pull onto something that doesn't look like road surface... or the obstructions that aren't... or the pedestrians who have clearly signaled you that they're not going to move. We're not anywhere close to solving these problems, so we'll require humans to be able to drive in situations where the computers will refuse to. (At the endpoints of routes, the map data is particularly likely to be garbage, too.)

The other side is trickier still-- small nuances that change how you drive. A kid running down the sidewalk by themselves encourages you to drive a lot slower because those little fuckers are erratic. However, requiring a human driver to pay attention during all circumstances erases a lot of the advantages of

Never, ever, ever compare 3Q to 4Q.

getting zapped with 20 coulombs kinda makes sense, though.

If it's unjust enough, yes.

First, if we hold people immune/not morally responsible for whatever they do as part of misbehaving organizations, we've removed one of the final checks and balances from these organizations. We've effectively capitulated, saying that when you get enough people together they can turn into a crushing, evil leviathan, as long as there's not a blatantly clear organizational criminal conspiracy. People should be people, making (and held accountable for) moral judgments about the actions they take.

My former boss made a mistake with the whole AMT thing. He exercised below market rate stock options and held the stock until the value went to 0. He made no actual money, but ended up with a tax liability and IRS employees systematically liquidating his assets. There are supposed to be things in the organization to protect against this-- an ombudsman, proscriptions against proceeding with such blatantly unfair and unaffordable collection practices, etc. He's in his late 60s and they just took everything. I think the people who didn't pull the organizational lever to stop the process, presumably because it wasn't helping them meet their collection targets, should be in prison.

You can try it in the cloud for free for small datasets/poke around by signing up at http://stormdb.com/ .

The database server itself is a little harder to deploy than PostgreSQL, but we have a fairly decent set of documentation (feedback appreciated) at http://files.postgres-xl.org/d... . As far as application support goes--- if it runs on Postgres, odds are it will run on Postgres-XL.

Sure, and it inherits from Postgres-XC significant code.

However, it has a few things Postgres-XC doesn't. First, if you write a complicated join, Postgres-XC sends the entire tables involved in the join back to the coordinator node, which then promptly dies/grinds to a halt. Postgres-XL has a planner that is able to A) push down much more of complicated queries, and B) allow tuples involved in sophisticated queries to flow directly between the different data nodes.

Postgres-XL's planner is also able to run large queries in parallel across the entire system (MPP).

Finally, we've done a fair bit to improve both stability/maturity and to eliminate various kinds of bottlenecks that were bottlenecking OLTP performance. We also have some small additional features (multitenancy-- hiding stuff from the catalog people shouldn't see and making databases true isolated containers). On the other hand, we are also missing some features that Postgres-XC has because of our focus on stability and production readiness.

Really premature, and unlikely in any event.

I think Postgres is good for what it is-- a clean, single-node database system. Clustering adds some complexity in deployment (we're working on making this easier) that you wouldn't want to incur for a typical Postgres install.

I think there are pieces of Postgres-XL that make sense to be in core/vanilla PostgreSQL, and we'll be working to contribute them upstream. Likewise, there are more pieces from TransLattice's commercial database offering, TED, that Postgres-XL could benefit from that we intend to contribute.

Honestly, just organizational readiness. We are likely to move to a BSD-style license in the future... but initially taking a license that made it a little harder to have a closed-source fork was easier to convince some members of the team/board. (There's been a significant amount of investment in producing this codebase and we wanted to make sure we didn't immediately enable a competitor).