Of every tv show where a bomb has a convenient countdown clock on it. In the old days it was an alarm clock wired to the bomb, then it was changed to a red digital timer because progress.

Anyone remember the movie V for Vendetta? Conveniently, V's bomb in the control room had a countdown clock so the guy who had no idea what he was doing knew how many seconds he had left.

You might say waiting 2 days for a free delivery is super bad inconvenient,

Only whiners living in their parent's basement would say this. For nearly everything one could buy (excluding groceries), two days is insignificant. If you're in that much of a hurry to get something, either an emergency has come up or you're too stupid to plan ahead.

In your case it might simply be that there was not enough of this kind of tasks in the training data.

I agree in general, but not with this strong phrasing. I've let AI build a good amount of non-trivial code. But my consistent experience is that it works best when guided by an experienced coder who can correct it, and when implementing well-known algorithms rather than coming up with novel solutions.

Example: I let it write up a quadtree implementation in a language for which there was no ready solution online. It took 2-3 correcting prompts to get a good result. I could've done it myself but it would've likely taken a few hours to get it all right instead of the half or so hour it took with AI. The important part for me was that there's nothing unknown in how to implement a quadtree. All the AI needs to do is take the 100s of existing implementations and translate them into a different language.

True but too simplified. The Luddites had an entirely different motivation: The fact that factories now employed women and children at very low rates meant that the men lost their status in the family as bread winners and head of household. That was a major social disruption, which we don't have with AI.

I'd compare it more to teamsters or wagoners when cars became common. Your job is threatened by a different way of doing the same thing, a way to which your skills don't cleanly transition. Some choose to pick up the new tech, some want the old ways to persist.

In the end, coachmen became chauffeurs, because rich people prefer to be driven around oder driving themselves, no matter if it's a horse or an engine doing the pulling. But much fewer teamsters and wagoners became truck drivers.

There's no such thing as a US Army smartphone. They use Samsung Galaxies and iPhones. Those have IMEIs, MAC addresses, IMSIs, MSISDNs, Android Identifiers, and Google Advertising IDs, just like any other phone.

BOTH of them? :-)

I'm sure you're familiar with the countdown protocol, all the pre-flight checks, etc. These power up a range of subsystems, motors, etc, so that everything can be verified prior to ignition itself. The complete sequence takes a very long time. Under normal flight conditions, you can't check for absolutely everything (instrumentation is mass, and mass is the enemy) but there's still a lot. However, during an engine test, you can pack a lot more sensors in.

This is where you'd want to be spotting loose connections, pumps that aren't quite even, pressures that aren't as steady as they should be, vibrations that shouldn't be there or do not match expectations, turbulent flows, and so on.

At ignition, it takes between 3-6 seconds to go from stopped to 90% thrust. For humans, that's near-instant. For a computer sensor that's operating a million samples per second, that's 3-6 million readings. A computer performing a billion calculations per second shouldn't have much difficulty in comparing 3 million readings against model predictions and determining if both the values themselves and the rate of change at each point such a sensor exists are all good. Emergency shutdowns during those first 3 seconds are perfectly viable.

Vibrations are the ones that are likely the most interesting, because those are likely to change before something breaks, not sure how fast you can make infrared sensors, but that's also an area where things are likely to alter before point of failure.

Lazy, yes. Bright, no. If you can't trust the average person to figure out that bread that's loaded with salt and sugar isn't healthy, then you can't trust the average person to figure out what a healthy balanced meal is.

The exact scenario we warned about when the discussions about this "responsible disclosure" nonsense started. Someone needs a reminder that letting you know your software sucks is a courtesy, not something you can demand.

The evolutionary pattern was created because food was unreliable and energy demands were unpredictable - but high, due to the large brain. (Possibly larger than it is today, but there seems to be conflicting data there.)

Now, rationing extreme energy foods is certainly one option, but it's not a particularly satisfactory one as the energy demands vary by profession and by time within a profession. You simply can't predict what people will need and there's no way to standardise this.

There is a second option. Intense focus is impossible for beyond about 45-90 minutes at a stretch, or for more than 3-5 hours in a day. Meetings degrade intelligence, according to psychological research, so you want to minimise those. After about 7 hours, work will mostly have negative value. If you increase the amount of high physical activity for at least an hour a day (and potentially longer if the amount of soft work is minimal in the job) then you will improve physical fitness and general health, without having to substantially alter diet. However, that still only gets you so far, because a poor diet still impacts physical and mental health, and can lead to brain decline. (It's a big factor in poor brain health in children in schools.)

A third option, then, is to actually improve meal quality in schools and for workplaces to work with the food industry to provide cheaper/easier access to high quality foods that actually taste good, not merely sensible energy foods. This would seem to be target solution, with in-work exercise to supplement it.

Half the posts: AI is dumb, do not want, is anybody actually asking for this?

Other half: Siri is dumb, it's Apple's worst product, it's why I use Android.

They probably were. Every single thing cranks say isn't necessarily wrong, especially with enough retrospective eye squinting. The very best cranks take a grain of truth, inflate it out of proportion and use it to sell you their expensive vitamin C pills and blueberry powder.

If that turns out to be the case, we get to find out something about what reshaping the brain means.

Whilst that is perfectly true, it is questionable as to whether it is useful or necessary. If a rocket is being tested, then logically it should be heavily instrumented. If it's heavily instrumented, and the instruments are themselves competently designed, there is no obvious reason why the engine can't be auto-cut when problems start to arise. And they will have arisen long long before the explosion.

The values may have independently been "within permitted range", but if the pattern of those values doesn't make sense, then something has gone wrong. There may well also have been subsystems that were insufficiently instrumented.

"They're the experts" is often an irrelevancy - we lost TWO shuttles and crews to political decisions, when the experts on the ground were ignored. DeHavilland lost endless Comets to basically the same blunder, when political decisions by management over the reality of metal fatigue overrode analysis by actual experts. Improper monitoring and inadequate computer controls will be from a burden of costs and time (both political constraints, not engineering constraints). As, indeed, will improperly manufactured parts, improper software (anyone rememebr Arianne IV's mishap due to buggy software?), improperly-defined constraints, and inadequate quality controls.

The experts are usually either well aware of mistakes or afforded no means of detecting them.

I see no reason not to think this was anything other than a management blunder.