frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Open in hackernews

Loose wire leads to blackout, contact with Francis Scott Key bridge

https://www.ntsb.gov:443/news/press-releases/Pages/NR20251118.aspx
73•DamnInteresting•1h ago

Comments

DamnInteresting•1h ago
Video explanation: https://www.youtube.com/watch?v=bu7PJoxaMZg
bmelton•50m ago
That was super helpful. I was assuming from skimming the text description that it was a failed crimp

A lot of people wildly under-crimp things, but marine vessels not only have nuanced wire requirements, but more stringent crimping requirements that the field at large frustratingly refuses to adhere to despite ABYC and other codes insisting on it

Aurornis•36m ago
> A lot of people wildly under-crimp things

The good tools will crimp to the proper pressure and make it obvious when it has happened.

Unfortunately the good tools aren't cheap. Even when they are used, some techs will substitute their own ideas of how a crimp should be made when nobody is watching them.

psunavy03•1h ago
Although I was never named to a mishap board, my experience in my prior career in aviation is that the proper way to look at things like this is that while it is valuable to identify and try to fix the ultimate root cause of the mishap, it's also important to keep in mind what we called the "Swiss cheese model."

Basically, the line of causation of the mishap has to pass through a metaphorical block of Swiss cheese, and a mishap only occurs if all the holes in the cheese line up. Otherwise, something happens (planned or otherwise) that allows you to dodge the bullet this time.

Meaning a) it's important to identify places where firebreaks and redundancies can be put in place to guard against failures further upstream, and b) it's important to recognize times when you had a near-miss, and still fix those root causes as well.

Which is why the "retrospectives are useless" crowd spins me up so badly.

drivers99•58m ago
> it's important to recognize times when you had a near-miss, and still fix those root causes as well.

I mentioned this principal to the traffic engineer when someone almost crashed into me because of a large sign that blocked their view. The engineer looked into it and said the sight lines were within spec, but just barely, so they weren't going to do anything about it. Technically the person who almost hit me could have pulled up to where they had a good view, and looked both ways as they were supposed to, but that is relying on one layer of the cheese to fix a hole in another, to use your analogy.

kennethrc•35m ago
Likewise with decorative hedges and other gardenwork; your post brought to mind this one hotel I stay regularly where a hedge is high enough and close enough to the exit that you have to nearly pull into the street to see if there's oncoming cars. I've mentioned to the FD that it's gonna get someone hurt one day, yet they've done nothing about it for years now.
avidiax•18m ago
Send certified letters to the owner of the hedge and whatever government agency would enforce rules about road visibility. That puts them "on notice" legally, so that they can be held accountable for not enforcing their rules or taking precautions.
crote•6m ago
The problem is that they are legally doing nothing wrong. Everything is done according to the rules, so they can't be held accountable for not following them. After all, they are taking all reasonable precautions, what more could be expected of them?

The fact that the situation on the ground isn't safe in practice is irrelevant to the law. Legally the hedge is doing everything, so the blame falls on the driver. At best a "tragic accident" will result in a "recommendation" to whatever board is responsible for the rules to review them.

astrocat•43m ago
this is essentially the gist of https://how.complexsystems.fail which has been circulating more with discussions of the recent AWS/Azure/Cloudflare outages.
stackskipton•36m ago
>Which is why the "retrospectives are useless" crowd spins me up so badly.

As Ops person, I've said that before when talking about software and it's mainly because most companies will refuse to listen to the lessons inside of them so why am I wasting time doing this?

To put it aviation terms, I'll write up something being like (Numbers made up) "Hey, V1 for Hornet loaded at 49000 pounds needs to be 160 knots so it needs 10000 feet for takeoff" Well, Sales team comes back and says NAS Norfolk is only 8700ft and customer demands 49000+ loads, we are not losing revenue so quiet Ops nerd!

Then 49000+ Hornet loses an engine, overruns the runway, the fireball I'd said would happen, happens and everyone is SHOCKED, SHOCKED I TELL YOU this is happening.

Except it's software and not aircraft and loss was just some money, maybe, so no one really cares.

Aurornis•13m ago
> Which is why the "retrospectives are useless" crowd spins me up so badly.

When I see complaints about retrospectives from software devs they're usually about agile or scrum retrospective meetings, which have evolved to be performative routines. They're done every sprint (or week, if you're unlucky) and even if nothing happens the whole team might have to sit for an hour and come up with things to say to fill the air.

In software, the analysis following a mishap is usually called a post-mortem. I haven't seen many complaints about those have no value. Those are usually highly appreciated. Thought some times the "blameless post-mortem" people take the term a little too literally and try to avoid exploring useful failures if they might cause uncomfortable conversations about individuals making mistakes or even dropping the ball.

thaumasiotes•10m ago
> Basically, the line of causation of the mishap has to pass through a metaphorical block of Swiss cheese, and a mishap only occurs if all the holes in the cheese line up.

The metaphor relies on you mixing and matching some different batches of presliced Swiss cheese. In a single block, the holes in the cheese are guaranteed to line up, because they are two-dimensional cross sections of three-dimensional gas bubbles. The odds of a hole in one slice of Swiss cheese lining up with another hole in the following slice are very similar to the odds of one step in a staircase being followed by another step.

tialaramex•1h ago
Note that "Don't make mistakes" is no more actionable for maintenance of a huge cargo ship than for your 10MLoC software project. A successful safety strategy must assume there will be mistakes and deliver safe outcomes nevertheless.
gishh•1h ago
The date for bridge completion was bumped from 2028 to 2030 already. I assume it won't be done until 2038. It is absolutely murdering traffic in the Baltimore area, not having a bridge. I would be super interested in seeing where every single dollar goes for this project, I assume at least 1/3 of it will be skimmed off the top.
1970-01-01•57m ago
So there were two big failures: Electrician not doing work to code; inspector just checking the box during the final inspection.
nightpool•48m ago
No, there was a larger failure: whoever designed the control system such that a single loose wire on a single terminal block (!) could take down the entire steering system for a 91,000 ton ship.
bragr•30m ago
There's a 3rd failure: the failure to install/upgrade dolphins that could deflect a modern containership, despite the identified need for such. That proposed project seems cheap in retrospect.
nightpool•14m ago
Yes, 100%. Lots of failures across the board here. Especially with large ships and how many different nations they might be registered in, I can't imagine it's easy to have a lot of regulatory oversight into their construction, mechanical inspection or maintenance schedules. I'm curious how modern ports handle this problem, feels like it could cause a ton of issues beyond just catastrophic ones like this one.
IncreasePosts•24m ago
The terminal blocks could also have been designed to aid visual inspection.
buildsjets•52m ago
In a well engineered control system, any single failure will not result in a loss of control over the system.

Was a FMECA (Failure Mode, Effects, and Criticality Analysis) performed on the design prior to implementation in order to find the single points of failure, and identify and mitigate their system level effects?

Evidence at hand suggests "No."

CGMthrowaway•32m ago
"Catastrophe requires multiple failures – single point failures are not enough. The array of defenses works. System operations are generally successful. Overt catastrophic failure occurs when small, apparently innocuous failures join to create opportunity for a systemic accident. Each of these small failures is necessary to cause catastrophe but only the combination is sufficient to permit failure. Put another way, there are many more failure opportunities than overt system accidents. Most initial failure trajectories are blocked by designed system safety components. Trajectories that reach the operational level are mostly blocked, usually by practitioners."

https://how.complexsystems.fail/#3

jojobas•29m ago
Most cargo ships have a single main engine with plenty of backup-less failure points. They are sort of engineered so these failures can't happen suddenly but you can help yourself to a bunch of videos on how substandard fuel and parts shortages cause week-long poweroffs in a middle of the ocean.
Aurornis•8m ago
> In a well engineered control system, any single failure will not result in a loss of control over the system

That's true in this case, as well. There was a long cascade of failures including an automatic switchover that had been disabled and set to manual mode.

The headlines about a loose wire are the media's way of reducing it to an understandable headline.

comeonbro•44m ago
A label placed half an inch wrong on misled affordance -> 200,000 ton bridge collapse, 6 deaths, tens of billions of dollars of economic damage

Instant classic destined for the engineering-disasters-drilled-into-1st-year-engineers canon?

Where do you think it would fit on the list?

bragr•27m ago
I guess this will still be bellow Therac-25 for CS and CE students, but above for EE, ME, and Civil Engineering.
ocdtrekkie•11m ago
The image brings to mind the Cisco ethernet boot infographic: https://www.cisco.com/c/en/us/support/docs/field-notices/636...
jtokoph•44m ago
It’s been noted that automatic failover systems did not kick in due to shortcuts being taken by the company: https://youtu.be/znWl_TuUPp0
fabian2k•38m ago
The big problem was that they didn't have the actual fuel pumps running but were using a different pump that was never intended to fulfill this role. And this pump stays off if the power fails for any reason.

The bad contact with the wire was just the trigger, that should have been recoverable had the regular fuel pumps been running.

jojobas•37m ago
"Contact" is a weird choice of words.
charles_f•16m ago
Thought the same, bridge is fallen on its entire length, sounds like a way to undersell it. Such an opportunity to pass on clickbait is interesting in this day and age.
dhosek•5m ago
I’m not sure that the NTSB is really in the clickbait business. But yes, contact does seem to really be underselling the event.
dopamean•24m ago
I know a little about planes and nothing about ships so maybe this is crazy but it seems to me that if you're moving something that large there should be redundant systems for steering the thing.
gk1•19m ago
There are.[1] Unfortunately they take longer to employ than the crew had time.

[1] Add it happens I open with an anecdote about steering redundancy on ships in this post: https://www.gkogan.co/simple-systems/

crote•16m ago
I strongly recommend watching/reading the entire report, or the summary by Sal Mercogliano of What's Going On In Shipping [0].

Yes, the loose wire was the immediate cause, but there was far more going wrong here. For example:

- The transformer switchover was set to manual rather than automatic, so it didn't automatically fail over to the backup transformer.

- The crew did not routinely train transformer switchover procedures.

- The two generators were both using a single non-redundant fuel pump (which was never intended to supply fuel to the generators!), which did not automatically restart after power was restored.

- The main engine automatically shut down when the primary coolant pump lost power, rather than using an emergency water supply or letting it overheat.

- The backup generator did not come online in time.

It's a classic Swiss Cheese model. A lot of things had to go wrong for this accident to happen. Focusing on that one wire isn't going to solve all the other issues. Wires, just like all other parts, will occasionally fail. One wire failure should never have caused an incident of this magnitude. Sure, there should probably be slightly better procedures for checking the wiring, but next time it'll be a failed sensor, actuator, or controller board.

If we don't focus on providing and ensuring a defense-in-depth, we will sooner or later see another incident like this.

[0]: https://www.youtube.com/watch?v=znWl_TuUPp0

Aurornis•9m ago
Thanks for the summary for those of us who can't watch video right now.

There are so many layers of failures that it makes you wonder how many other operations on those ships are only working because those fallbacks, automatic switchovers, emergency supplies, and backup systems save the day. We only see the results when all of them fail and the failure happens to result in some external problem that means we all notice.

pstuart•6m ago
Hopefully the lesson from this will be received by operators: it's way cheaper to invest in personnel, training, and maintenance than to let the shit hit the fan.
ocdtrekkie•15m ago
"and WAGO Corporation, the electrical component manufacturer"

Sucks to be any of the YouTubers influencers today telling everyone they should use WAGO connectors in all their walls.

Seriously though, impressive to trace the issue down this closely. I am at best an amateur DIY electrician, but I am always super careful about the quality of each connection.

rootusrootus•5m ago
I don't see anything in the report that suggests the connector failed. It sounds like the installer failed. Trust me, they can screw up twist connections too :)

The Death of Arduino?

https://www.linkedin.com/posts/adafruit_opensource-privacy-techpolicy-activity-739690336223705497...
284•ChuckMcM•2h ago•149 comments

Loose wire leads to blackout, contact with Francis Scott Key bridge

https://www.ntsb.gov:443/news/press-releases/Pages/NR20251118.aspx
76•DamnInteresting•1h ago•39 comments

Building more with GPT-5.1-Codex-Max

https://openai.com/index/gpt-5-1-codex-max/
260•hansonw•4h ago•155 comments

Europe is scaling back GDPR and relaxing AI laws

https://www.theverge.com/news/823750/european-union-ai-act-gdpr-changes
370•ksec•7h ago•416 comments

Researchers discover security vulnerability in WhatsApp

https://www.univie.ac.at/en/news/detail/forscherinnen-entdecken-grosse-sicherheitsluecke-in-whatsapp
23•KingNoLimit•1h ago•4 comments

Meta Segment Anything Model 3

https://ai.meta.com/sam3/
126•lukeinator42•4h ago•28 comments

Static Web Hosting on the Intel N150: FreeBSD, SmartOS, NetBSD, OpenBSD and Linu

https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openb...
82•t-3•4h ago•30 comments

It's your fault my laptop knows where I am

https://www.amoses.dev/blog/wifi-location/
12•nicosalm•15m ago•1 comments

Cognitive and mental health correlates of short-form video use

https://psycnet.apa.org/fulltext/2026-89350-001.html
119•smartmic•2h ago•93 comments

How to identify a prime number without a computer

https://www.scientificamerican.com/article/how-to-identify-a-prime-number-without-a-computer/
16•beardyw•1w ago•6 comments

Pozsar's Bretton Woods III: Sometimes Money Can't Solve the Problem

https://philippdubach.com/2025/10/25/pozsars-bretton-woods-iii-the-framework-1/2/
28•7777777phil•2h ago•8 comments

Launch HN: Mosaic (YC W25) – Agentic Video Editing

https://mosaic.so
96•adishj•6h ago•89 comments

Thunderbird adds native Microsoft Exchange email support

https://blog.thunderbird.net/2025/11/thunderbird-adds-native-microsoft-exchange-email-support/
268•babolivier•10h ago•70 comments

Screw it, I'm installing Linux

https://www.theverge.com/tech/823337/switching-linux-gaming-desktop-cachyos
36•throwaway270925•44m ago•15 comments

Show HN: DNS Benchmark Tool – Compare and monitor resolvers

https://github.com/frankovo/dns-benchmark-tool
34•ovo101•4h ago•25 comments

Larry Summers resigns from OpenAI board

https://www.cnbc.com/2025/11/19/larry-summers-epstein-openai.html
130•koolba•8h ago•129 comments

A $1k AWS mistake

https://www.geocod.io/code-and-coordinates/2025-11-18-the-1000-aws-mistake/
257•thecodemonkey•12h ago•223 comments

Control LLM Spend and Access with any-LLM-gateway

https://blog.mozilla.ai/control-llm-spend-and-access-with-any-llm-gateway/
43•aittalam•1w ago•10 comments

Exploring the limits of large language models as quant traders

https://nof1.ai/blog/TechPost1
90•rzk•14h ago•81 comments

What Killed Perl?

https://entropicthoughts.com/what-killed-perl
113•speckx•11h ago•251 comments

Comparing Integers and Doubles

http://databasearchitects.blogspot.com/2025/11/comparing-integers-and-doubles.html
15•pfent•1w ago•7 comments

The Future of Programming (2013) [video]

https://www.youtube.com/watch?v=8pTEmbeENF4
138•jackdoe•6d ago•86 comments

Racing karts on a Rust GPU kernel driver

https://www.collabora.com/news-and-blog/news-and-events/racing-karts-on-a-rust-gpu-kernel-driver....
9•mfilion•1h ago•1 comments

Reproducible C++ builds by logging Git hashes

https://jgarby.uk/posts/git_repr/
26•j4cobgarby•5d ago•27 comments

Netherlands returns control of Nexperia to Chinese owner

https://www.bloomberg.com/news/articles/2025-11-19/dutch-hand-back-control-of-chinese-owned-chipm...
74•boovic•3h ago•33 comments

Multimodal Diffusion Language Models for Thinking-Aware Editing and Generation

https://github.com/tyfeld/MMaDA-Parallel
120•lnyan•12h ago•13 comments

The peaceful transfer of power in open source projects

https://shkspr.mobi/blog/2025/11/the-peaceful-transfer-of-power-in-open-source-projects/
176•edent•8h ago•121 comments

To launch something new, you need "social dandelions"

https://www.actiondigest.com/p/to-launch-something-new-you-need-social-dandelions
56•curiouska•4h ago•9 comments

How two photographers transformed RAW photo support on Mac

https://petapixel.com/2025/11/14/how-two-photographers-transformed-raw-photo-support-on-mac/
53•gbugniot•4d ago•26 comments

Learning to Boot from PXE

https://blog.imraniqbal.org/learning-to-boot-from-pxe/
77•speckx•10h ago•33 comments