Hacker News Reader

Comment by cwizou | Hacker News Reader

Same thing happened to British Airways a few years ago on a 787, a misplaced security pin that was inserted in the wrong place during a maintenance operation. There are two very similar holes next to one another that can receive the pin, there's a picture at the bottom here : https://aviation-safety.net/wikibase/318989

Wondering if the same mishap is behind it again.

View on HN

The report on that incident says there was a hardware modification to make this impossible, to be incorporated before Jan 2023.

(It also says this happened to Boeing in 2018 and they ignored it, of course)

I missed that part, and since it's a newly delivered plane (this January), it's safe to assume the mitigation was in place. Preliminary report will be interesting here.

Wonder why they don't just grab a huge permanent Sharpie and write in huge letters "Do not insert pin here" on one hole and "Insert pin here" on the other hole.

I'm actually serious, it seems to me they resist these kind of short-term helpers that would save lots of injuries.

I think the report says they just put a little cover on the hole where the pin shouldn't go (but can).

Sure, but they probably took 3 years to have a design review, an executive review, some firings and layoffs, re-hire, orientation, a sprint planning meeting, a sprint retro, a post mortem, an OKR meeting, a KPI meeting, an all-hands, and then the cover probably got stuck in customs with tariffs, and then the tolerances probably weren't correct.

Meanwhile the sharpie would take 1 minute.

> Meanwhile the sharpie would take 1 minute.

And eventually be missed/ignored by a rushed ground tech and fail again.

Other than making it easier to blame someone, labeling is just a short term interim fix for such things. You design it to be physically impossible or as close to that as possible.

Been there, done that in much less high stakes environments. Upping the training, documentation, and labeling simply makes the mistakes happen less often for a physical process obviously prone to a common mistake.

Sure as an immediate airworthiness directive giant bright lettering is a great immediate “this month” fix. Certainly not a permanent one though.

If you make a hole multiple things can be fit into, eventually someone will try.

You’re likely a fan of this: https://i.sstatic.net/vaPH0.jpg

Yikes, mojibake in 2021.

edit: actually, how did that happen? The apostrophes show up correctly, they’re just all preceded by a Â that doesn’t seem to represent anything?

They're probably Microsoft's "Smart Quotes", which are Unicode. They were presumably stored in UTF-8 but retrieved as ASCII (or ISO-8859-1).

The page is declared as ISO 8859-1, but the actual bytes of the text appear to be UTF-8. In UTF-8, characters from U+0080 to U+00AF happen to be encoded as C2 <codepoint value>. For example, U+0092 is encoded as C2 92.

C2 in ISO 8859-1 is ”Â”. U+0092 is the control code Private Use 2 in Unicode, and 92 is the same in ISO 8859-1. However, the standard Western Windows code page 1252 extends ISO 8859-1 by assigning “’” (right single quotation mark) to 92.

HTML5/WHATWG requires an ISO 8859-1 charset declaration to be interpreted as Windows-1252 (https://blog.whatwg.org/the-road-to-html-5-character-encodin...), hence the displayed result is “Â’”.

The original Windows-1252 content must have previously been converted to UTF-8 under the assumption that the source is ISO 8859-1, i.e. mapping 92 to U+0092 (Private Use 2) instead of to U+2019 (Right Single Quotation Mark). The resulting UTF-8 encoding was placed in the web page, which however is declared as ISO 8859-1.

Delicious, thank you!

I edited my post after verifying the actual bytes, it turned out to be slightly more complicated.

The double-encoding path gets you there too: the original UTF-8 \xE2 \x80 \x99 mis-decoded as iso-8859-1 or Windows-1252 and saved back as UTF-8 gives \xC3 \xA2 \xC2 \x80 \xC2 \x99, which in Windows-1252 renders as Ã¢Â€Â™. A WYSIWYG cleanup replacing that mojibake with the Windows-1252 ' (byte 0x92) and saving back as UTF-8 gets you to \xC2 \x92 on disk.

Edit: Although maybe that's not the most parsimonious explanation.

In my post the sequence is:

1. Mis-transcode Windows-1252 as ISO 8859-1 to UTF-8.

2. Mis-decode UTF-8 as Windows-1252.

this one does g11n....

Anyone who has any mechanical inkling would see that the NLG rotates around the massive bushing and putting a pin in there won’t stop anything.

The aircraft is 1 year old and was delivered in January...

But, fucking hell, apparently Boeing "engineers" are so dumb they never learned about Murphy's law.

I bet you would blame the automotive engineers too after reversing your car through the garage door.

You mean like the death of Anton Yelchin, where poor gearshift design made it incredibly easy to confuse whether the car was in gear or in park?

Yeah, that is indeed primarily on the engineers.

What kind of person parks on a hill without setting the parking brake?

Well, Chekov is not Scotty

Advice: You really should look up how the engineers designed the gear lever, before voicing more of your ignorant "knowledge".

Edit: Oh you're talking about the parking brake, not the gear lever. Smells of victim-blaming.

Grandparent post:

> There are two very similar holes next to one another that can receive the pin, there's a picture at the bottom here : https://aviation-safety.net/wikibase/318989

> Wondering if the same mishap is behind it again.

I'm commenting on the genius of this design. Even if yesterday's accident isn't due to this design, how dumb can you be to design something like that, it's what Murphy's Law says to not do.

I’d be far more likely to suspect Boeing’s management for pushing unsafe schedule or staffing and having things slip through the cracks. They have a reputation.

Reply on news.ycombinator.com