Please, no. Often when writing code I need the API reference and only the API reference. I know what I want to do and how to do it, I just need a quick check of the exact order of arguments or exact symbol names. I don't need to try to sift that out of commentary. Likewise when I'm learning how to use the library I'm more interested in the overall view. I don't need to know the exact names of the options for a call, only what the options are for. I expect the code in the user's guide to be accurate, but I don't want the same things out of it that I want out of the API reference.

Except for the bit where it does that caching for a loop where each lookup only occurs once. Because everybody caches lookups, so that must be the right thing to do (it's the most likely thing to happen) in a case where the cache is never used. Riiiiight...

Something critical to note: intent is the most important thing to document when it comes to software. You can see what it does by reading the code, that's straightforward. What I need to know most, both when writing software and maintaining it later, is why it's doing that. What's it supposed to be doing? Why is it doing it in that way? What were the alternatives and why weren't they chosen? How is it supposed to be used by code that calls it? An LLM can't generate any of that just from the code.

This is why traditionally software libraries have had two separate pieces of documentation: an API reference that details every call and it's arguments and results, and a user's guide that lays out how and why to use the library.

In 1971, 'Creeper' proved the concept of a computer virus. Years later, experts were calmly and sometimes patiently explaining to people that you couldn't get a virus from an email.

Then Microsoft threw the weight of it's huge dev team into the effort and finally made the email virus a reality.

Now, 30 years later, LLMs have at last given teeth to "the honor system virus".

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.

No, it definitely isn't. Between the radiation, tendency to accumulate in bone, and shedding pyrophoric flakes, it's really not safe to handle.

Without doubt, some Trump flunky will sell a hundred kilos to IBM.

Only to find out it's not the business machine people, it's Iranian Boom Makers.

Not much. Plutonium isn't like uranium, it's effectively safe for human contact outside its fissioned form. This has been pretty well documented.

This is a step forward which is a long time overdue. It should've happened 30 years ago, and we'd have averted having to depend on China for our electricity production (wind + solar) without the net-zero production problems those two 'sources' introduce.

This has been typical behavior for large companies when dealing with vulnerability reports for decades. Report one, they treat you as the problem. They'll try to ignore it, consider it "not exploitable", delay and deflect as long as they can get away with it, anything but address the vulnerability. And they'll never tell anyone the vulnerability exists. This only changes when they have no choice but to admit to the problem and fix it, usually when the vulnerability is being publicly exploited. They push "responsible disclosure" because it includes the reporter not making the vulnerability public until the company has a fix, which allows them to stall disclosure as long as they want.

It used to be enough to just include a reasonable deadline when reporting it, after which the reporter would make it public if the company hadn't taken some action on it. Then companies started threatening and then taking legal action against the reporter as soon as they reported the problem, playing the deadline up as "blackmail".

So, what do you do when faced with this? The only reasonable response is to skip the company entirely and make the details public immediately. You're going to be facing retaliation from the company either way, this way the public isn't vulnerable for an extended time. And yes you include details on how to exploit the vulnerability, ideally via working code, so researchers other than the company can confirm it's a real vulnerability that's actually exploitable without having to take your word for it. No, that doesn't give the bad guys anything because remember the working assumption for vulnerabilities: if a good guy has found it, the bad guys already know about it and are using it. Remember that when the company whines.

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 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.

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.

Each state that gets money in a judgement or settlement, should use that money to make sure their public education system teaches kids how to block ads.

By 2030, I don't think anyone should be able to graduate high school in America, unless they've learned how to be ad-free (on screens under their control; obviously they won't gain superpowers to blank out billboards or the sides of buses).

Bezos suffers Projectile Dysfunction.