Yes, the view looks great through those rose-tinted glasses. I did all those unsafe things you mentioned, but there is a big difference between doing all those things and what the Chinese are proposing. The only one who took the risk was me. If I screwed up, only I suffered. The consequences of failure in this grand scheme being concocted are not limited to China alone, and if we all take the risk, then we should all have a say in this endeavor, and we should all benefit from it.

This is somewhat like the BP oil spill. The spill may have occurred outside of US territorial waters, but it sure as hell impacted the US. And the US will certainly want a say in what oil companies do when drilling offshore, because of the fiasco we witnessed.

I get the humour, but the tower of Babel was supposed to have been located in Mesopotamia - i.e modern Iraq

Yes, Airbnb is a service that doesn't provide any value (why do they exist, again?), but thats not the problem here. Even if they did provide verification of the renter, it would still be stupid to rent out ones apartment exposing private and personal information to some stranger. In this case, the landlord realized that her identity was at risk because the place had been comprehensively trashed. A smarter thief would have simply noted down all the personal data would letting the landlord suspect anything. And because the identity theft using this data could happen many months later, it would be difficult to pin this down to a specific renter.

There is no escaping the fact that landlords like this need a reality check. Maybe the world is filled with people who do and want to do the right thing, but why would you take a risk like this assuming that no bad apples would come in contact with you?

She didn't _prove_ him wrong. You can walk across a busy highway, and by some miracle escape being hit by a vehicle. That doesn't prove that everyone who told you that you are doing something stupid was wrong.

Maybe this is your experience, having come from working on applications that serve mom and pop shops, but don't assume that your experience is the same as everyone else's. Mine is the opposite of yours. Most applications are engineered for maintainability and very often, when compromises are made in shipping things out the door, it is often the function points that are left on the floor, rather than shipping function points backed by unmaintainable code.

The only exceptions to this that I have seen have been in shops which are so small that the development team lacks an architect who can enforce this discipline, and you have a team consisting of prima donnas. I'm not saying that small teams can't deliver good code. Just that most of the screwups that I've seen come from small teams operating without any discipline (and they typically lack the discipline because they think they are small enough to operate in that mode).

You are mostly correct, though you didn't mention the key word: control system. The patent that the Wright Brothers file was not for the shape of the plane, or the engine they used, but for the control systems that let them control the pitch, yaw, and roll of the aircraft. Indeed, controlling the aircraft in stable flight by defining parameters like pitch, yaw, and roll was a key insight of theirs. All their competitors weren't able to achieve stable flight because they were still guessing their way around how to keep their aircraft up and steady, and didn't really have a solution that let them control the aircraft.

With respect to your comment that this is a logical fallacy - its not so. The pitot tubes have been for the past two years the #1 reason put forward as the cause - by a wide margin. There have been no alternative theories so widely championed. Go back through the news articles and see for yourself. If you find that too difficult, you can use the wikipedia page on this disaster (look at the page history).

I don't understand what you are trying to say here. You seem to be conceding that this was a commonly occurring failure, and don't dispute that this wasn't fixed (i.e it was ignored), so why am I wrong?

Not quite free fall. My back of the envelope calcuations (38000 feet in 3 mins 30 secs) shows that assuming constant acceleration, the descent acceleration would have been approx .5 m/s^2 . This is about what you would experience in an elevator going down before the elevator reaches constant speed.

What seems to be remarkable is that the trigger to the catastrophe has indeed been revealed to be the pitot tubes - something that was suspected very soon after the flight went down. To a layman like me, it is amazing that without the benefit of all the data that has been recovered from the flight data recorders, experts were able to get so close to the mark.

Now, one could flip this around and also say that given that so many observers were able to so accurately get to the initial trigger for the failure in the absence of hard data, it must mean that this was a really common failure mechanism that should occurred in the field only as a result of the problem being repeatedly ignored.

It is a triumph of technology that the flight data recorder survived under such extreme conditions for so long. It was a triumph of technology, that it was located and retrieved from such an extreme location. Surely, a species with such (magical?) technical expertise could have expended the effort into preventing such a failure?

This location makes more sense. According to other sources, the intersection of Awami road and Kakul road (the spot where it says "PMA Kakul") is approximately where the helicopter went down. This would make it in the flight path to / from the Afghan border, rather than the swing-around-and attack from the South implied by the other location.

Quite the contrary, it is deservedly unknown. Have you tried to do programming with Dojo? The documentation is terrible. You can never figure out how to accomplish even the most trivial of tasks if you even wander an inch off the beaten path shown in the examples. Ever heard of the phrase "An undocumented feature is a feature that doesn't exist"? By that token, Dojo is the javascript framework that has the least set of features.

I also have a problem with the way the library is structured - it is painfully hard to extend the library. For example, one of the "dijits" provided is a tree widget. Instead of a "normal" node, I wanted to extend the widget by having each non-leaf tree node be a checkbox, but doing this turns out to involve putting out huge chunks of code.

Obama was for the bailouts even when he was a presidential candidate. He actively campaigned for it in the senate and helped Bush pass the TARP bill. There was no shift in his policy once he assumed office because from day one he had said that while it was evil, it was a necessary evil.

I think you have a very limited view of what kind of programming folks do. Only a small percentage of folks do programming at the level where they need to know how a processor works. The vast majority of programmers out there work in high level languages like Java or SQL or XSLT where the nature of the processors capabilities, whether it is RISC or CISC or whether it is a multi-processor or uni-processor systerm doesn't matter a bit to what they are delivering. A lot of times you have assembler bigots on /. spouting things like "...you can write fast / efficient code if you don't understand how the processor works" or if you haven't programmed in assembler. I don't believe this. In the real world out there, what matters most in a huge percentage of projects speed of delivery of function points. If one has to compromise between a 30% efficiency improvement by using a lower level language, vs a 50% improvement delivery time by using a higher level programming language, then that 50% improvement will be the deciding factor in your company making a profit and therefore keeping you employed.

I have done programming in assembler. I have done programming C, C++, COBOL, VisualBasic, Lisp, and a whole bunch more languages for over 20 years. And my experience is that knowing how the processor works or a stack works, isn't helpful in 99% of cases..

I don't deny that in the embedded space, or to system programmers, that these details aren't important. But those programming spaces are a small portion of the programming market.

Did you read the Foundation series? His "seeing-the-future" was based on large groups of people having a predictable history - never the individual. In fact, when the "Mule" appears, that event completely throws off the predictions of psychohistory. The "seeing-the-future" in the Minority Report is specifically about the future history of individuals. Azimov gave a plausible explanation of how psychohistory might work. The Minority Report gives an explanation, but believing in it requires the suspension of a scientific mind. And thats my point - the film may be entertaining, but based on solid science isn't something one can say about it.

Aw...come on. Seriously - the "Minority Report"? The ability of people to see the future is based on solid science? This must be some new definition of the word "science" that I wasn't aware of.

There are other science glitches in the other movies too. For example, in "The Abyss", the underwater creatures miraculously rewire human physiology to not require decompression chambers when the entire diving platform is lifted up to the surface. But I'll let those slide in the name of dramatic license. But the ability of those three "precogs" to see the future is central to the plot of the story and its hard to ignore that gaping scientific hole in the plot of the Minority Report.