Live data from Hacker News

We found an undocumented bug in the Apollo 11 guidance computer code

juxt.pro

101–110 of 213 posts

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#101
post #23

Earlier quoted context omitted.

This is the top reply on a substantial percentage of HN posts now and we should discourage it. It is: - sneering - a shallow dismissal (please address the content) - curmudgeonly - a tangential annoyance All things explicitly discouraged in the site guidelines. [1] Downvoting is the tool for items that you think don't belong on the front page. We don't need the same comment on every single article. [1] - https://news…

It's not a shallow dismissal; it's a dismissal for good reason. It's tangential to the topic, but not to HN overall. It's only curmudgeonly if you assume AI-written posts are the inevitable and good future (aka begging the question). I really don't know how it's "sneering", so I won't address that.

It’s a dismissal with no evidence i.e. it’s a witch hunt. And no one should support that.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#102
post #24

Has someone verified this was an actual bug? One of AI’s strengths is definitely exploration, f.e. in finding bugs, but it still has a high false positive rate. Depending on context that matters or it wont. Also one has to be aware that there are a lot of bugs that AI won’t find but humans would I don’t have the expertise to verify this bug actually happened, but I’m curious.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

They have some spec language and here,

https://github.com/juxt/Apollo-11/tree/master/specs

have many thousands of lines of code in it.

Anyways, it seems it would take a dedicated professional serious work to understand if this bug is real. And considering this looks like an Ad for their business, I would be skeptical.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#103
post #10

Earlier quoted context omitted.

For what it’s worth, Pangram thinks this article is fully human-written: https://www.pangram.com/history/f5f68ce9-70ac-4c2b-b0c3-0ca8...

Then pangram isn't very good, because that article is full of Claude-isms.

Pangram has a very low false positive rate, but not the best false negative rate: https://www.pangram.com/blog/third-party-pangram-evals

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#104
post #93

Earlier quoted context omitted.

I disagree. I like to read articles and explore Show HN posts, but in the past 6 months I’ve wasted a lot of time following HN links that looked interesting but turned out to be AI slop. Several Show HN posts lately have taken me to repos that were AI generated plagiarisms of other projects, presented on HN as their own original ideas. Seeing comments warning about the AI content of a link is helpful to let others kn…

> you’re reading an AI expansion of someone’s smaller prompt, which contained the original info you’re interested in This got me thinking: what if LLMs are used to do the opposite? To condense a long prompt into a short article? That takes more work but might make the outcome more enjoyable as it contains more information.

> This got me thinking: what if LLMs are used to do the opposite? To condense a long prompt into a short article? That takes more work but might make the outcome more enjoyable as it contains more information.

You're fighting an uphill battle against the inherent tendency to produce more and longer text. There's also the regression to the mean problem, so you get less information (and more generic) even though the text is shorter.

Basically, it doesn't work

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#105
post #14
post #2

Super 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

the subheadings are extremely AI IMHO

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#106

Still my all time favorite snippet of code. TC BANKCALL # TEMPORARY, I HOPE HOPE HOPE CADR STOPRATE # TEMPORARY, I HOPE HOPE HOPE TC DOWNFLAG # PERMIT X-AXIS OVERRIDE https://github.com/chrislgarry/Apollo-11/blob/master/Luminar...

Can you explain this to me?

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#107
post #62

For anyone who liked this, I highly suggest you take a look at the CuriousMarc youtube channel, where he chronicles lots of efforts to preserve and understand several parts of the Apollo AGC, with a team of really technically competent and passionate collaborators. One of the more interesting things they have been working on, is a potential re-interpretation of the infamous 1202 alarm. It is, as of current writing, p…

And that's why it's harder (or easier?) to make the same landing again -- we taking way less chances. Today we know of way more failure modes than back then.

It's a miracle nobody died in flight during the program. Exploding oxygen tank, rockets shaking themselves to pieces during launch, getting hit by lightning on top of a flying skyscraper full of kerosene and liquid oxygen....

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#108
post #67

Earlier quoted context omitted.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

>It's not even clear if AI was used to find the bug It's not even clear you read the article

Where do you think my confusion came from? All it says is that ai assists in resolving the gyroscope lock path, not why they decided to model the gyroscope lock path to begin with.

Please, keep your offensive comments to yourself when a clarifying comment might have sufficed.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#109
post #62

Earlier quoted context omitted.

And that's why it's harder (or easier?) to make the same landing again -- we taking way less chances. Today we know of way more failure modes than back then.

It's a miracle nobody died in flight during the program. Exploding oxygen tank, rockets shaking themselves to pieces during launch, getting hit by lightning on top of a flying skyscraper full of kerosene and liquid oxygen....

Starting from the first test pilots, a lot of people died for us to get to the point to launch that flight. So while no one died on the flight, lots of people died just getting us there. If I recall, in The Right Stuff, it's mentioned that those early test pilots had something like a 25% mortality rate.

Re: We found an undocumented bug in the Apollo 11 guidance computer code

#110

Earlier quoted context omitted.

It's not even clear if AI was used to find the bug: they mention modeling the software with an "ai native" language, whatever that means. What is not clear is how they found themselves modeling the gyros software of the apollo code to begin with. But, I do think their explanation of the lock acquisition and the failure scenario is quite clear and compelling.

How did you pick out AI native and miss the rest of the SAME sentence? > We found this defect by distilling a behavioural specification of the IMU subsystem using Allium, an AI-native behavioural specification language.

That does not answer my confusion, especially when static analysis could reveal the same conclusion with that language. It's not clear what role ai played at all.
Post reply on HN