Both the article and repo[1] are slop.
[1] In the repo, the "reproduce" is just a bunch of print statements about what would happen, the bug isn't actually triggered: https://github.com/juxt/agc-lgyro-lock-leak-bug/blob/c378438...
We found an undocumented bug in the Apollo 11 guidance computer code
151–160 of 213 posts
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#152Earlier quoted context omitted.
The early jet age was pretty nuts. Check the Wikipedia page for a random fighter from the era and you'll see figures like, 1,300 built, 50 lost in combat, 1,100 lost in accidents. And that's operational aircraft. Test pilots were in even more danger.
You should go back even a little further, the USPS air mail service lost 31 of the first 40 pilots.
Back in the days where the plan was "So we've built literal signal fires and giant concrete arrows and well, good luck, it won't help"
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#153Super interesting. I wish this article wasn’t written by an LLM though. It feels soulless and plastic.
It's not setting off any LLM alarm bells to me. It just reads like any other scientific article, which is very often soulless
It repeats a few points too many times for a professional writer to not catch it.
I don’t mind that they let an LLM write the text, but they should at least have edited it.
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#154Software that ran on 4KB of memory and got humans to the moon still has undiscovered bugs in it. That says something about the complexity hiding in even the smallest codebases.
My guess is that in such low memory regimes, program length is very loosely correlated with bug rate. If anything, if you try to cram a ton of complexity into a few kb of memory, the likelihood of introducing bugs becomes very high.
Well you don't have room for a lot of "defensive" code. You write the program to function on expected inputs, and hope that all the "shouldn't happen" scenarios actually don't happen.
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#155Earlier quoted context omitted.
The early jet age was pretty nuts. Check the Wikipedia page for a random fighter from the era and you'll see figures like, 1,300 built, 50 lost in combat, 1,100 lost in accidents. And that's operational aircraft. Test pilots were in even more danger.
Some were pretty bad, but none were nearly that bad. The B-58 Hustler lost 22% of its airframes, the F7U Cutlass 25%, the F-104 Starfighter in German service lost 33%. And those were outliers.
You're right, those numbers are from the F-8 but include non-total-loss accidents.
I don't think the numbers you quoted are outliers, though. The F-100 lost ~900 out of 2,300. The F-106 lost ~120/342. That's a pretty big list of planes with a 1/5-1/3 loss rate.
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#156Earlier quoted context omitted.
I have nothing against em dashes. As long as your writing is human, experienced readers will be able to tell it's human. Only less experienced ones will use all or nothing rules. Em dashes just increase the likelihood that the text was LLM generated. They aren't proof.
Evidently there are no experienced readers who post AI accusations.
Same weight as "there are no experienced men who'll ask a woman if she's pregnant."
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#157Earlier quoted context omitted.
Stop voting up slop articles and I'll stop commenting on it.
Point to one.
This is on the front page now https://rajnandan.com/posts/taste-in-the-age-of-ai-and-llms/
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#158Earlier quoted context omitted.
It's (what they're describing is) just reverse engineering. That's what reverse engineering is.
Fortunately reverse engineering too is in the dictionary - to help anyone mistaking it for spec generation.
Implying that I did make such mistake, which I did not, unless you're willfully taking me overly literal.
Nor did they make any mistakes when they described how they produced a specification, (and indeed, that it is a specification) despite your insinuation otherwise, for a similar reason.
Maybe instead of pointing towards dictionaries, stop pretending that you lack reading comprehension, and get off of your high horse please.
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#159Earlier quoted context omitted.
Here's one tell-tale of many: "No alarm, no program light." Another one: "Two instructions are missing: [...] Four bytes." One more: "The defensive coding hid the problem, but it didn’t eliminate it."
That's just writing. I frequently write like that. This insistence that certain stylistics patterns are "tell-tale" signs that an article was written by AI makes no sense, particularly when you consider that whatever stylistic ticks an LLM may possess are a result of it being trained on human writing.
No, it’s pretty obviously AI written. Not sure why you’re running so much interference for them…are you affiliated with this company?
Re: We found an undocumented bug in the Apollo 11 guidance computer code
#160Earlier quoted context omitted.
In theory, wouldn't be too hard be to settle the question if whether he used ChatGPT to write it: get Olang to write a few paragraphs by hand, then have people judge (blindly) if it's the same style as the article. Which one sounds more like ChatGPT.
When people judge blindly, the are more likely to think the human is the AI and the AI is the human. 73% judged GPT 4.5 (edit: had incorrectly said 4o before)to be the human. https://arxiv.org/abs/2503.23674 Not only are people bad at judging this, but are directionally wrong.
There is research showing the contrary that is far more convincing:
> Our experiments show that annotators who frequently use LLMs for writing tasks excel at detecting AI-generated text, even without any specialized training or feedback. In fact, the majority vote among five such “expert” annotators misclassifies only 1 of 300 articles, significantly outperforming most commercial and open-source detectors we evaluated even in the presence of evasion tactics like paraphrasing and humanization.