Forgot your password?
typodupeerror

Comment Reminds me (Score 1) 128

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.

Comment Re:subscribe to Amazon Prime now (Score 1, Troll) 31

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.

Comment Re:Space is still hard (Score 1) 73

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.

Comment Re:Maybe the world we made is a bit shit (Score 1) 112

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.

Comment Re:Space is still hard (Score 1) 73

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.

Space

Blue Origin Rocket Exploded Thursday Night During Hot-Fire Test (cbsnews.com) 73

Spaceflight Now shared their video of the explosion, which the Orlando Sentinel describes as showing Blue Origin's rocket "become engulfed in flames. The fireball expands out and covers the entire launch pad as the fuselage of the rocket can be seen crumbling into the flames."

Blue Origin founder Jeff Bezos said on X.com "It's too early to know the root cause but we're already working to find it. Very rough day, but we'll rebuild whatever needs rebuilding and get back to flying. It's worth it." (SpaceX founder Elon Musk posted "Sorry to see this, I hope you recover quickly.")

It's unclear how this will impact future launches. "The rocket was destroyed," reports CBS News, "and as the smoke cleared, there was no sign of the erector-gantry used to move the New Glenn from its hangar to the pad and to raise it from horizontal to vertical. Likewise, one of two tall lightning towers was no longer visible." It was the first such on-pad explosion at the Cape since a SpaceX Falcon 9 rocket blew up on nearby pad 40 on Sept. 1, 2016... Blue Origin only has one New Glenn pad, the one that was damaged in the Thursday test. The New Glenn, which has launched three times, is a heavy lift rocket designed to compete head-to-head with SpaceX Falcon 9 and Falcon Heavy rockets. During New Glenn's most recent flight in April, an upper stage malfunction prevented a commercial internet satellite from reaching its planned orbit...

The New Glenn destroyed Thursday was to send 48 Leo internet satellites owned by Amazon into space [which were not on board for the hot-fire test]

Blue Origin posted on X.com that "Debris from our recent hotfire anomaly may wash ashore in the coming days/weeks. If you encounter any debris, do not touch or approach it for your safety."

"Spaceflight is unforgiving, and developing new heavy-lift launch capability is extraordinarily difficult..." NASA Administrator Jared Isaacman posted on X.com. "âWe will provide information on any impacts to the Artemis and Moon Base programs as it becomes available."

Thanks to long-time Slashdot reader symbolset for sharing the news.

Submission + - The oral tradition that built software may not survive AI (fastcompany.com)

smooth wombat writes: Writing software is not just about knowing what to code. Verbally passing on knowledge of why something is done one way or the other, how to diagnose an issue, or what changes took place after implementation because no one documented those changes has been part of programming since day one. However, with the advent of AI, that institutional knowledge may be under threat.

It’s tempting therefore to imagine that generative AI will step into the breach and solve this for us. After all, even if you don’t want to turn a large language model (LLM) loose on a legacy code base—and there are plenty of reasons that you shouldn’t—having it generate documentation on the codebase itself might sound like a solution to the absence of other written information. LLMs can certainly summarize code back to you.

But hold up with that idea. Beyond hallucinations, there’s a deeper problem: Writing documentation is itself part of the thinking process. Whether I’m writing history or software, putting an approach into words helps refine it before I sink hours into implementation. Documentation also captures intent. An LLM may be able to summarize what a codebase does, but it cannot reliably explain why a developer chose one approach over another, or what trade-offs shaped that decision.

Moreover, it’s a chance for somebody else to understand why you did what you did. If they plan to change what I wrote (especially in a few years), they might understand why I needed to write it that way and what might be lost if you take it out. An LLM can read code that I’ve written. It might even scan a large codebase and accurately summarize what it’s doing. But it can’t assess authorial intent.

Slashdot Top Deals

There is hardly a thing in the world that some man can not make a little worse and sell a little cheaper.

Working...