we can look at this more holistically than a specific IT project. like in china, which is not a place i want to live, it is still valid to say, their process of steamrolling past local interests means that airport expansion and transit to new airports can be built quickly, which helps meet demand for air travel better than working at the absolute limits of safety and efficiency tradeoffs.
local control in the US infests everything. it causes airports to be too small, guilds to grow too slowly, it opposes infrastructure, it makes politicians too vulnerable and too weak to make changes that upset minor but powerful real estate interests.
so in one POV, safety is a blocker to reasonable change, but everywhere else in the world, they just increase capacity, and the huge stresses on safety limits are reduced.
In one role, I worked on writing software for drones.
That very rigorous process was very reassurring to me. Reasonable progress was absolutely occurring.
> One of the eng I worked with was 80+ years old and just didnt want to retire. He did not understand modern systems at all and the risks we were looking at were not (imo) realistically balanced.
What kind of risks were you looking at with what kinds of balances, if you're able to share?
The SRM board knew the legacy system but much less the modern one. Its hard to compare safety when you only clearly understand one systems safeguards.
I appreciate the process being there but at the time it felt much more like (some) people protecting their jobs than the public.
The risks I felt were overblown (iirc) were around likelihood of catastrophic failure in the system.
I actually loved the overall process and it informed how I look at software, it was the application of the process that bothered me.
Insomuch as people protecting their jobs: that's always a thing. But I honestly felt that people wanted to protect their jobs because they wanted to protect the public. Some people definitely wanted to keep their work and personal life separate with solid 9-to-5 boundaries. That's perfectly OK too. It was helpful to be inclusive of them even if their time was already filled.
I worked with numerous people who didn't understand all of the components or systems. We took it upon ourselves to be very open to questions and to thoroughly explain how each thing works. I've found if someone had good understanding of one component but didn't understand another component, it was very useful to schedule time with them to walk through the components they didn't understand to try to alleviate their concerns. They might not know what questions to ask, so I would instead ask questions about their well-known components to try to understand and correlate to newer components. Perhaps their concerns were even justified but they didn't know how to articulate them!
Iirc there were 1 or 2 people who could hold the process up and were not open to persuasion.
I was also young and less equipped to handle that.
I worked in a few other spaces and liked a slightly more balanced approach.
Silicon Valley style approach is not what id strive for at the FAA. I dont think that is the extreme they have swung to either.
And then there are the safety issues.
> Iranian schoolgirls were killed by assumably an AI-directed decision.
Version control was always something that was adopted more by process-heavy organizations until the popularization of GitHub. Before that, it was common for the move-fast type of developers to eschew version control.
Earlier in my career, people didn't bother with the chore of using version control unless they were working on an important project that demanded it.
Some slight rigor shows you are not just doing whatever. I found most projects once you scale past 2 or 3 people and your 3rd release you basically are forced into some sort source control. Or it is a game of 'what file did they break today and I have to spend 3 hours fixing before I can add my feature'. Then you end up with merge meetings and very weird things happening.
Usually missing source control in an older org means there is a large swath of tech debt. Watch for the weeds. You will find other things very quickly.
Idk, I feel like the difficulty of Git (which is real in some respects) has long been exaggerated by people who are categorically unwilling to RTFM.
If this is the case, why was an airport knocked offline due to a cut fiber optic? A safety focused system would have a backup system say satellite or mobile 4G/5G. But they didn't have such.
This isn't about safety. Its about bureaucracy wrapped up as safety.
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...
'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. 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.
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...
But creating a bureaucracy doesn't mean you've created a rigorous process to ensure safety.
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.
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.
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.
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.
There were two independent systems.
You can argue thats not a sufficient third redundancy, I don't have enough context to throw an opinion out there on the safety of this particular infrastructure project.
I am confident that the fallback process was considered and kept in place as the tertiary backup.
Excellent point though. It took me some thinking to put myself back in SRM mindset and what they'd have considered here.
Not really. Triplex redundancy is based on a failure model where failures can produce arbitrary output. Three systems allows majority voting (often, median select) to provide correct output in the presence of a single arbitrary failure. It allows detection of double-fail-silent failures and uncorrelated double failures, but that's not really the point, since continued operation under these conditions is at risk, and failing nonoperational isn't often acceptable for these systems. (You'll also see quadruplex systems that use the same voting mechanism to detect and disable failed channels, allowing handling two arbitrary non-simultaneous failures, for systems that need a longer window of continued operation after failure.)
If you change the failure modes, you change the architecture. These days you often see dual-dual systems where each pair of systems cross-checks and disables itself on mismatch, converting a single arbitrary failure to a single silent failure; which then allows downstream systems to accept inputs from two such fail-silent systems and trust either that is providing output, removing the need for a median select.
What’s a better way? We still don’t have state-regulation/certification for software in safety critical systems, which terrifies me when I think about it.
The pilot no longer had flight controls. He desperately tried to control the airplane using variable thrust, but it just wasn't good enough, and crashed into a mountainside.
The fix was to add automatic valves in the lines so loss of pressure wouldn't bleed out the whole system.
So in reality you didn't have two systems.
otherwise you would have shut down operations until you had another connection live, so you had 2 online connections.
Also, there's a big difference between a small towered airport in a more rural area, and a major international airport with 10x or more the commercial traffic. So there's probably some difference of buildout depending on the facility usage.
Quick edit: looks like there were two fiber cut incidents recently, one at an airport last month, and the TRACON issue that happened 1.5 months ago!
There is a strong difference between an airport going down and ATC causing and accident.
Uptime isn't safety, they have very orthogonal characteristics.
Can you provide any examples you've come across where the current administration has pushed safety to the side with respect to the FAA? I'm curious to read about those. I know there have been some changes to regulations and there are sometimes disagreements around those but I'm not sure if the ones I've seen (which aren't comprehensive) would be considered pushing safety to the side.
also I believe the OP is: https://news.ycombinator.com/user?id=bargl
I assume you're not running two accounts?
Basically when accident rates are already very low, even a small amount of transitional risk can add up to offset years of marginal improvements. So the burden of proof rests heavily on the proposer of change to a system that already is working reliably.
It is when you can't replace it, and drives do break.
Magnetic degradation, wear from read/write heads, and environmental sensitivity mean disks have a natural expiration date and it's not long. And they are also easy to cut out from all kinds of magnetic sources around us.
I get other stuff, even DOS like system. Safety critical software/hardware that was battle tested makes sense. Not floppy. Sometime it's just bureaucracy.
That they are still used in a critical infra item is a bit surprising. Getting new stock would be a major hassle.
This is probably my "I'm getting old" moment. Good lord.
People who grew up with or lived in the tech environment had access to lots of things.
YMMV. I’m sure a lot of people were shoving these things into backpacks, and this was post-2000, so the quality of disks for sale was poorer than it was in the 90s and 80s.
On the other hand, 3.5" disks have higher magnetic coercivity, which makes them less susceptible to data loss from stray magnetic fields (e.g. nearby motors).
Without having details on the specific floppy disks in question there’s no way you can authoritatively say they are unreliable. They absolutely produced floppy disks that were far more reliable than the ones sourced from the cheapest vendor possible some of us used in school back in the day. Ignoring the fact I’m guessing the disks in question aren’t having to survive life in a students backpack.
Is it because "long-term archival" strategies aren't updated frequently?
We switched them over to external USB enclosures with cheap SATA drives in them and never looked back.
One cost $100 another $1.
Then these tapes are typically write once read many.
They were designed to deal with floppy disk flaws consumers deal with.
Actually really cool to read about modern tape systems.
They absolutely mog the cancerous garbage that is NAND flash memory in terms of data retention. The fact that you can pick an 1980s floppy from the junk room and read it is telling. Meanwhile your average TLC SSD will probably get wiped in 3 years if kept in the drawer, and a QLC will get wiped in 1 year.
Reliability wise floppies are also better: flash memory leaks electrons naturally and gets shredded by radiation events, with temperaure accelerating these processes. Meanwhile magnetic disks are not altered by any normal magnetic field you could produce at home.
https://www.theguardian.com/uk-news/2026/nov/03/mogging-crow...
More info here: https://www.urbandictionary.com/define.php?term=mog
Say, the Siemens PLCs I earn my living programming uses SD cards which range from 64kB to, uh, 128MB, methinks.
They still work after decades, so clearly, you can get long term reliable flash storage; just don't expect to be able to store your 4k holiday videos on them.
NOTAMs, on the other hand? Go ahead!
SanDisk's Extreme Pro range will disagree with you on that front. I have never seen a worn out card out of that range.
If you compare the thumb stick that came free from a convention then compare it to a floppy that came free with a magazine. And in the end neither matters because they’re both cheapest possible junk, not fair examples of the tech.
Similarly, the cheapest led bulbs (put in poorly ventilated fittings) have crappy lifetimes, but that’s not the techs fault, it’s because they weren’t engineered to last, they are cheap crap. Well designed leds placed sensibly are vastly better than bulbs, but that’s hidden by the cheap end of the market
In cold storage, a hdd should last longer than an ssd
Check the logo on the picture on the right.
First, the cover uses italic sans-serif “I” characters, not forward slashes. It’s pretty clear if you’re familiar with typography.
Second, the body of the document uses neither. It uses the standard upright I character.
Call it weird if you want, but that's what the name was.
Second, the body of the document uses neither. It uses the standard upright I character.
The fact people have old working floppies doesn't change the fact that degradation happens.
I wonder if quality control was bad. It seems like the disks that were good 30 years ago are still good.
I’ve bought some 15 year old floppies recently. They work. Had just to learn, that formatting them is required. In handling they are like SD-Cards.
Which is far better than the CDs, DVDs, Bluerays or records (you now…this big black discs with a needle).
And you don’t have to worry about network attackers. And we checksum everything from the network. For good reasons.
Source: go to any used record shop and find a copy of Chicago >5[0]. It'll almost certainly play, even if the music wasn't particularly good to start with.
[0] There are many copies of later Chicago albums in used record stores.
Say what you will about floppies. There’s something to be said for a system that’s air-gapped by default.
I’m curious also something like Stuxnet would fit on a floppy disk? They hacked the Iranian centrifuges via USB virus.
It’s like getting car jacked and the perp realizes it’s a stick shift so they panic and run away.
Can you recall anything that that engineer said or did which turned out to be credible? Or which you perhaps learned from?
I would urge you not to consider this modernization from the perspective you may be familiar, as someone who may work on the bleeding edge and sometimes sees a lack of caution from engineers pushing for change.
The FAAs safety risk management is built around a rigorous process, but that is also a massive slowdown to reasonable progress.
One of the eng I worked with was 80+ years old and just didnt want to retire. He did not understand modern systems at all and the risks we were looking at were not (imo) realistically balanced.
I get the idea that the current administration is pushing safety to the side, but there is another risk where safety becomes a blocker to reasonable change.
When I left that work (more than 15 years ago) it was clearly a blocker.