I don't think the so-called slashdot effect is in effect these days except for casual and amateur sites. Pretty much any serious site can handle a hard slashdot hit any more.

Yes, he is amazing. He gives half of those SICP lectures as well, trading off with Hal Abelson, another great engineer and lecturer.

A rocket is a mass driver, and all of the "scifi" types of propulsion break the laws of physics one way or another. Space elevators would be pretty nice, but we still haven't found a material strong enough. Carbon nanotubes are the current hope, but we can't make them long enough yet; they'd have to be very long indeed to make a strong enough elevator. Short nanotubes have to be glued together and then you're down to the strength of the glue.

I got distracted and broke my links. An Electrical Engineering View of a Mechanical Watch is at http://video.mit.edu/watch/an-..., and the SICP lectures are at http://ocw.mit.edu/courses/ele...

For the most part it's a difference in magnitude. The speeds the rockets achieve are much higher than any airplane, let alone car, ever manages. The thrust of the engines is stupendous, the liquid H2 and O2 fuels are cryogenic, the flame temperatures in the engine are extreme. In fact, they're so extreme that the engines use precise control over the flow fuel and oxidizer entering the engine to create a layer of cooler gasses around the inside of the engine nozzle, so that it doesn't melt or ablate entirely away. Everything has to work in vacuum and at ambient air pressure and at max Q during flight.

All of this and more adds up to a much harder design problem, much more stringent test requirements, much tighter manufacturing tolerances, etc. The principle is the same, however; any change to one component of a system may require changes to every other component.

The one thing that all forms of engineering from (whether software, civil, aerospace, or other) have in common is the management of complexity. The automotive engineer designs the engine mounts in your car to accept a wide range of engines, so that they can manufacture several variants of the same car with different engines without having to redesign every component. Similarly, SpaceX has greatly reduced their cost and risk by reducing the complexity of their rockets; one way they did this was to use the same engine for both the first and second stages of their rockets (the first stage simply uses more of them). Another way was to avoid cryogenic fuels; they have a lower specific impulse (fuel efficiency), but a much greater space efficiency (liquid H2 is very light; that orange tank is huge, and 80% of it is for the H2 tank) plus you avoid having to deal with cryogenic fuels, and the complicated materials engineering that goes into designing the tanks to hold them.

If you want to know more, MIT has some great lectures on the subject, even ones suitable for non-engineers. A good one is An Electrical Engineering View of a Mechanical Watch . The description of this lecture only touches on superficial matters; Sussman's real point is that the means of abstraction present in an engineered system can be applied to any other engineered system, and that it's only by designing the right abstractions that engineers make continual progress in designing newer and better systems. He states this directly in the first two minutes, which is quite handy. You might also check out the video lectures for the Structure and Interpretation of Computer Programs , the first lecture of which goes into much the same topics in the realm of software engineering.

Unlike in Kerbal Space Program, when you stack rocket components on top of each other you have to reengineer the bottom one to hold up the top one; they say that they're reusing the main tank, but that might be true in a narrow sense if they reuse the H2 tank inside the orange Space Shuttle External Tank. Then you have to engineer the manufacturing processes and factories for producing any new components (and there will be lots of those), plus the modified one (easier, but still plenty to go around), plus you have to engineer the test facilities for all the components, and you have to test the test facilities, and then test the components, and then test-launch the vehicle, etc. Don't forget to document everything, and to design training procedures so that you can hire new people to build these things, and test them, etc, etc. It actually is rocket science.

Ukrainian tanks don't have reactive armor, as the article points out.

And sure, no one is suggesting launching nukes at Russia based on the evidence we have right now.

That's pretty normal for press coverage, for what it's worth: they have to fill up space, so will throw in unrelated pictures all the time...

Getting clear close-ups of stuff in a war zone is hard, of course, especially if the stuff is being hidden.

http://www.bbc.com/news/world-... has some photographs if you care.

CAs normally issue certs with 1-year validity. As they may not expire later than 2015-11-01, CAs will mostly stop issuing them on 2014-11-01. I guess you could ask them to cut a cert with a special, shorter lifetime but that would be hassle (and therefore extra cost).

> [citation please]

http://www.charlesmann.org/art... has a good summary.

CrimsonAvenger's point was that we've had evidence since the early 1800s that humans (and probably other hominids, in fact) ate mammoths. Nowhere did he say that humans were eating mammoths in the 1800s.

It's really not that complicated. Firefox releases work like this: 6 weeks of development, 12 weeks of testing and stabilization (split up into two 6-week phases called "aurora" and "beta"; the former corresponds more or less to feature freeze and the latter more or less to "code freeze unless we discover a stop-ship issue"), then release.

So right now 31 is released, 32 is beta, 33 is aurora, and development is happening on 34.

I suggest you take that browser from the old days, run it on today's web sites, and see how many hundreds of MB it takes. Assuming it loads them at all.

It's a matter of funding.

Looking at the chart at http://en.wikipedia.org/wiki/F... and in particular the inflation-adjusted line there tells you pretty much what the story was: at the peak of the Apollo program NASA's budget was about $40 billion/year in today's dollars (the red line in that graph is in 1996 dollars). NASA's budget today is less than $18 billion/year.

Or to put it in relative-to-the-economy terms, in 1966 NASA was 4% of Federal budget expenditures. 4% of the 2013 US expenditures (actual, not requested) would be $138 billion, according to http://en.wikipedia.org/wiki/2...

I bet if you funded NASA at that level (even just the inflation-adjusted one; I understand that the overall budget structure is quite different now from what it was in 1966, so the $138 billion number is pretty much meaningless), I bet it could produce results a lot quicker than it can at current funding levels...