In fact, it's created a bunch of risks. Like the fact that nobody manufacturers floppy disks or floppy disk readers anymore.

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.

It was bad enough in 1986 when F-16 pilots had to bring their own cassette players on missions.

https://www.youtube.com/watch?v=GVHEFiLQ3GU

The old man in me says this is a reference to the movie "Iron Eagle", without clicking on the link. :)

I worked for a salesforce partner and we spent the two years I was there working with a large ag equipment manufacturer. They had two legacy systems that were still (as I was told) some combination of Fortran and early Unix systems. They had been reluctant to upgrade them because one of the their main manufacturing machines was still running on it and they were terrified if they upgraded and something went wrong, it would cost them millions in production time.

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.

Fortran is still used in scientific computing.

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.

> 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.

> ...getting the current software running in a VM specifically to make it easier to transition to new hardware.

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

“NLA”?

no longer available

Fortran is still the choice for Nuclear Engineering too.

My understanding, from a long retired uncle (after a 40 year career at the National Institues of Health writing nothing but Fortran), is that Claude writes perfectly idiomatic, performant Fortran. Which I suppose is not a surprise given how it was trained, but I still found amusing to hear.

Have the idioms of Fortran changed much over the decades? Because idiomatic C++ today is unrecognizable to how people had to write for VC++ Win32 until well-until the 2010s.

Yes, infamously so. It was fixed-width at one point.

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.

Linux 7.4 got fixes for floppy disk handling, as recently as yesterday!

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

A bit odd that they didn't at least update to using USB thumb drives. Those are readily available and at least as reliable as magnetic floppy disks.

Yeah, that's what I'd have expected especially because I believe the USB mass media standard was part of the original standard. You'd need no special drivers to work with a modern USB thumb drive even if you are dealing with windows 98 (Win95 had usb support, but I believe you still had to install the drivers for it).

Not only drivers. The initial release of Windows 95 predates USB itself, so the entire USB stack didn't appear until later OEM service releases that AFAIK were never released as updates for existing installs or even as retail products (unless you count MSDN or OEM System Builder products with their associated license restrictions).

You can get floppy disks and USB-C floppy drives on Amazon. Drives are under $20.

Yup, it can create a situation where you have a huge incentive towards workarounds and hacky fixes because doing it properly incurs huge costs. This is especially bad when a fundamentally quite bad design makes it through certification (most processes don't really prevent this).

Presumably such a confident assertion is based on sufficient actual experience with slower safety protocols such that you can state, positively, that faster-moving processes produce safer, human-life critical, systems... ?

You really, really need to work in industrials controls before your opinion carries weight on this - there are plenty of 40 year old systems humming along keeping the world turning that are bulletproof reliable.

'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.

Yes - but those examples don't all have the same risk modalities. With dams and reactors, many failure variables can be permanently contained by initial system design/engineering and construction quality, continually inspected surroundings and internals, and physically known certainty. Human inputs are limited and daily inspection matters, but any momentary error or lapse of operator attention won't result in instant destruction. You have hours and days with Dams, minutes and hours with reactors. In aviation it only takes a split second.

Aviation involves constant unpredictable human inputs and physical states. Hundreds of vehicles, not installations. It is not yet solved, the status quo merely has a societally tolerable death rate. There are additional sensors, safety redundancy automations, and info synthesis/notification interfaces that are currently blocked by certain 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...

Creating a rigorous process to ensure safety will create somewhat of a bureaucracy.

But creating a bureaucracy doesn't mean you've created a rigorous process to ensure safety.

But moving faster and without accountability is generally worse.

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 feel a bit weird that I'm fairly certain that I read this discussion a while ago, in another post...

The problem is that in the FAA's domain, there are legitimately situations where bureaucracy is indispensable. For example, they just issued an AD to require inspections of a few specific bolts on early production 787s because Boeing thinks they MAY have bolted the wings on with incorrectly sized shims, which over a decade MAY contribute to accelerated fatigue on these parts. Not a single plane has crashed but this kind of thing has caused other planes to crash in the past.

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.

None of this needs bureaucracy in the sense of slow moving and manual processes with tons of unnecessary paperwork. If the FAA had enough people and automated as much of the process as possible it would actually improve safety, because they can take action as soon as it's needed without waiting for overworked staff to get through the backlog first.

I'm not saying that every part shouldn't be accounted for, or that new rules should be passed right away without a detailed evaluation. But if the FAA had a single integrated system for airlines, manufacturers and inspectors this bolt issue would be over a lot faster. They could send out a personalized alert to everyone recorded as operating an old 787, wait for them to upload the ultrasonic data, run the analysis and give immediate feedback if something needs to be replaced.

Even Boeing could flag the issue a lot faster if they had a good analytics pipeline looking for correlations between fatigue rates and different aspects of production. That would mean taking inspection results from all their customers, and only the FAA can help with that.

> If the FAA had enough people and automated as much of the process as possible it would actually improve safety, because they can take action as soon as it's needed without waiting for overworked staff to get through the backlog first.

You misunderstand the root of the issue: a single failure can lead to the deaths of hundreds of people and massive political blowback. Automation is great! Deploying automation always comes with headaches, and here the headaches would be unacceptable because they could easily lead to hundreds of people dying. Jetliners all already have fully digital datalinks, but clearances are still given over analog radio; pilots have the authority to decline a clearance whenever they feel it necessary. How would automation handle that?

The same administration software would have to work across the entire world, including in countries with different aviation systems and standards. Lots of airlines send jets for maintenance in different countries; they would need to trust this system over paper records.

FYI - the FAA is testing out ATC automation for general aviation, which is much more accident prone and therefore a better candidate than commercial aviation which has a sterling safety record. I think if it works there we might see it in commercial traffic, but it's a long road to get that many 9s.