These airplanes are flying all over the world, the inspections need ultrasonic data, and the FAA has to validate that all of them are done. Even identifying this issue required lots of bureaucracy.
Multiply that by the number of airplanes and airplane models and it's easy to see why they move so slowly: when you are putting millions of people in the air each day, enforcing absurdly specific rules with an iron fist requires a monster of a bureaucracy.
In a perfect world, we would move at a steady pace, as to keep up with the world but without rushing, and people would be accountable without a heavy bureaucratic processes.
Unfortunately, that's not how it works in practice, at least not for long, so between the two, we usually favor the slow and bureaucratic process when safety and reliability matter.
I can understand not changing a system for change sake, but the floppy disk has been obsolete for nearly 20 years now. It's been hard to find a floppy disk reader for the last 10 years. Going so slow that you can't respond to that change is far FAR too slow.
As you pointed out, you can't find floppy discs or disc manufacturers any more. I do remember one of the VP's of this company saying as long as they keep teaching Fortran to college engineers, they have no reason to upgrade yet. That got a few raised eyebrows from our team. We relented and upgraded what they were comfortable with - but man oh man it was quite the eye opener for me as a young dev how the thought processes of the people running these companies really are.
As long as those manufacturing systems were air-gapped and working, I can understand being conservative with changes. Of course at some point you're at risk of hardware failures too, for things that are likely NLA.
Yeah, that's really the biggest issue with these systems. Were I one of these manufacturers I'd invest in getting the current software running in a VM specifically to make it easier to transition to new hardware. The last thing they'll want to deal with is that their software was written for Sun Spark and that no longer exists.
That said, hard to go wrong porting over the x86 at this point.
Some of the signal control infrastructure for the Melbourne rail network was ported over to an emulated PDP-11 System for this reason. This was previously discussed on HN here: https://news.ycombinator.com/item?id=42514553
My humbling Claude experience was pointing at a codebase it took me weeks to get to a good 2003 standard, and watch it do the next fifteen years, cleanup, refactoring, feature additions that needed the tech debt solved I never got round to first, in minutes.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
But creating a bureaucracy doesn't mean you've created a rigorous process to ensure safety.
'Move fast and break things' is fine when the result of failure is someone failing to make a billion dollars at their IPO. It's not acceptable in the world where failure means dams break, reactors go supercritical, planes collide, or other similarly apocalyptic scenarios.
Aviation involves constant unpredictable human inputs and physical states. Hundreds of vehicles, not installations designed to have as few moving parts as possible. It is not yet solved, the status quo merely has a societally tolerable death rate. There can be new sensor hardware, more safety redundancies, and info synthesis/notification interfaces that are currently blocked by old hardware bottlenecks. Controller and pilot time and attention is limited, and it can be wasted less.
And inversely... when pilots leave too much to automation, their skills may degrade to the point that by the time you actually need a capable human crew because something has gone terribly wrong, the capability of that crew has degraded too much, and the FAA has warned about this in the past [1].
[1] https://medium.com/faa/the-dangers-of-overreliance-on-automa...