i work for aerospace, and this is fairly typical -- albeit not floppy disk examples, but we keep a bunch of old laptops running win 7 and other examples around, hound around for them and spare parts. these machines are off the network, etc.
these systems were developed 20+ years ago and per contract the a manufacture is obligated to maintain them for the service life, so unless these are obsoleted these are to last 20-30+ years.
the costs associated of porting all tools from win 7 to a newer system and re-verifying 50K+ test cases to do a similarity analysis run into astronomical in terms of $ and months (years) of work. no one really wants to poke that bear so you have situations like these.
It is interesting that people don't think on these scales. What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?
Because I've seen a bit of that and it's what makes the world go round. There's certainly a lot of bad/crazy stuff out there but wonder if the ephemeral fashions of today will stand the tests of time.
I wrote a piece of software that still handles all engineering project management for one of the larger communications companies in North America (>2.5 million customers). I developed it in 1997 and it is still in place today, chugging away for ~400 daily users and getting minor updates a couple times a year. I didn't remotely think it would last on this timescale and I have paid the price for some poor design decisions many times over. Still, as much as I cringe at some of the older sections of code, it has been nice to see it keep going.
The client has started internal projects to replace it 3x over and each has been cancelled; sum total spent on the cancelled projects easily exceeds what I charged by an order of magnitude. In retrospect I didn't charge nearly enough back then! If only I could have used a SAAS model.
The best-practices we teach our experimental physics students, whether they know it or not, are generally designed to yield experimental apparatus that can last a decade or more with minimal maintenance.
After you've lived through it, a decade is a very short span of time. If you don't have to think about whether or not something is going to break, you have more free cycles to think about something else that needs doing.
I'm in my 30s, I've been a primarily web developer for 15 years, and I know there is software I wrote in 2008 that is still running today for processing the rent of 1000s of residents. It has been updated a few times, adding a console argument to automate the process more. It was originally a Bob-O-Matic process. At midnight on the first of the month, this old-timer Bob would launch the application, click one button to load the residents, double check the numbers, click another the button to pull the rent statements, check those numbers, and then click a third button to process the transactions which actually took about an hour to run through, and on occasion would actually crash once a year or so, but it had the ability to pick back up after a crash where it left off.
That was probably my first real bit of production code, it (un)fortunately replaced half a floor of people with one man, who faithfully clicked those buttons every first midnight for the next 10 years before he retired. It was then automated by the couple of South African contractors that replaced the NYC-based app development team.
The company spent about 12 years automating away almost every job except management.
It was meant to be a temporary solution until the online payments module was developed by the vendor. Yet, here we are in 2020 and that module still hasn't been delivered. And no one who worked there initially is even around any longer.
If I'm not mistaken, we even gave them our code back in 2009 or 2010.
I built a relatively simple system over 10 years ago that ran on PHP and MySQL. Over the years, the company I built the product for has come back to me to upgrade PHP and MySQL after a security scan. The problem is the software was build for PHP 5.4, and they want it running on the latest (7.4). It doesn't.
I managed to get it running on the latest security release of 7.1 with a few days of work (I had to make code changes in the framework I used that weren't supported in PHP 7 anymore). If they want future security upgrades, it's going to require a even more significant rewrite of the software because it relies on old PHP behaviours that have been removed in recent releases.
So, I completely understand why 20 year old systems would still rely on floppy disks.
I charge my proofreaders a euro every time they miss 'built' spelled as 'built'. It's been a pretty steady money maker, that one. I make a ton of spelling errors as well so who am I to cast that particular stone but the built-with-a-t one seems particular hard to get rid of even when you know about it.
Some code I wrote in a drunken haze has been running continuously for 7 years with zero downtime - it was only meant to be temporary!
It has zero comments, the code was inefficient, the variable names are things like "theThing" (it's the best I could do at the time) and "database" is just a series of text files carefully read/written to on the disk.
In my first job we did project/information management systems. Initially for civil engineering projects, later more generally for governments and enterprises.
In some cases we had to have contingency plans for the software and data in case the company goes out of business within the coming 15 years.
Next I worked in advertisement, where clients spent similar sums as the above for cross media campaigns lasting maybe 14 days
That was quite the interesting contrast work wise :)
This is why at my last job we had a rule that said prototypes could not be shipped as production software. It had to be either completely rewritten, or at least completely code reviewed and the "bad" parts rewritten.
I approach this by writing exploratory prototypes with good modular boundaries, but stub/hacky implementations. Keeping it simple lets me throw modules away as I refactor, until everything's been rewritten and then I ship it.
Sure, and that works great for a personal approach to code. But when your lifecycle from requirements through release needs to be validated, something more scalable is required. Sometimes that scalable thing is "anyone shipping prototype code will be fired."
> It is interesting that people don't think on these scales. What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?
> Because I've seen a bit of that and it's what makes the world go round. There's certainly a lot of bad/crazy stuff out there but wonder if the ephemeral fashions of today will stand the tests of time.
Not many, I'd wager. I've even seem a few people argue here (IIRC) that backwards compatibility is an antipattern, which is the thing that allows systems to function on scales longer than an ephemeral fashion.
>>> What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?
Did that a lot when I was working at a major US bank (JP Morgan). All the critical software I worked on was planned for 10-20 years in my mind. Some of the work was upgrading/rewriting ancient things that have been there for 15 years, sometimes mostly untouched. Wrote some blog posts about it.
Retired the last Perl software in the bank, rewrote in python and made sure it works on 2.6 and 2.7 and 3.7 to cover the upcoming decade. That software was handling in the order of a trillion dollars per day, wouldn't be surprised if it's still there in 30 years. https://thehftguy.com/2020/06/26/are-banks-still-using-perl-...
> What percentage of the HN crowd has developed something that has had (or will have) a 10, 20 or 40 year life span?
I'm also curious about the work/personal split here. I have a small handful of things at home I first wrote around 10-12 years ago that I still use and tweak, but have only been working professionally for about 9 years (and have worked on things in that time I personally fully expect to hit 20-30 years).
Whatever the average age of the HN crowd is would probably inform a little. I'm 34 and have been a dev for about 8 years. The only code from a past job that I know for a fact is still in use today is something that I wrote in early 2017 (a let's encrypt integration for a web host). So about three years. I'm very curious to know how it has been updated since but I'm no longer at that job.
True of course. I just found the contrast between "people don't think in those scales" and the comment section interesting - and generally think that a surprising amount of code survives for a decade or more.
I built an invoicing / international shipment documentation generation / stock control / production tracking system with Excel and VBA and it's been in production for close to 20 years! I am conflicted as to whether or not I should be proud of that. ;)
I have stuff I wrote 15 years ago still in daily use from 500+ people to produce news which is seen by tens (hundreds?) of millions of people, last serious development on it was 2012, written in perl of course. Another system a colleague wrote from the same time, written in PHP, looks after image archives. I don't believe that's changed much either.
There's a lot of infrastructure stuff that dates back 12 years, when we standardised the entire place on ubuntu (804) for linux (and got rid of solaris at the same time).
That's all fairly new though. A lot of broadcast equipment still in use store config on 3.5" floppy disks, and I saw a windows 3.1 machine still running in a branch office about 18 months ago.
It's not ephemeral - when you think about upgrade cycles and deprecation of tech.
What I would claim - is that people who targeted Win95 for equipment that had to last decades never bothered to understand how software ecosystem works. They just "threw it together"...
That said - the floppy disks isn't that bad, per se. I would have expected Boeing to be smart enough to expose a data loading interface, that can read something "as if it was a floppy disk"... But then I look af 737 and Boeing's failure to deliver a crew space launch vehicle - and get reminded that they only exist because US government literally props it up.
A slightly different spin has been working on some 20+ year old C/C++ code that is relatively nicely written, such that you can still expand on it today.
I had a lot of joy recently reading the Voyager 1 image decompression routines and some X11 window manager sources.
I used to work for a manufacturers that had industrial equipment that was 15 years old. We had 15 year old PCs to talk to it. That was about 20 years ago. From what I hear, they’re using the same equipment, and same PCs.
35 years means they must be using 286s to run that stuff. On the plus side, nothing requires fans, the motherboards are extremely simple (albeit a mess of logic chips), and your biggest worry is probably the power supply. Right?
I dunno. I could easily see taking decently made hardware to the 20 year mark.
MS is extending extending free Windows 7 security updates to voting systems so that the US can get trough 2020 elections.
There is still Itanium hardware running on Windows Server 2008 R2 (Same Kernel as Win 7) and it's supported until at least 2025.
Safety critical and big enterprise software contracts are often written to keep the system running and updated with minimal changes and cost "Until the iron gets tired".
Perhaps people are surprised sometimes by how amazing maintenance and reliability engineering in the field really is. A small example like having these machines use a medium which some of the younger crew haven't even heard of is a nice reminder of this. Sure maintaining backwards-compatibility has a cost, but so does constantly rewriting everything that already works.
I worry how companies will be able to provide similar services in the future, as more and more stuff is running as services in the cloud.
It’ll most likely become more and more costly, as you won’t be able to buy offline version of some complement, and keep it working on your support device for 30 years. You’ll need to build all of them yourself. And that will also most likely mean it’ll be less reliable.
Then you "just" don't use those services. It's not rocket science ...ok sometimes it literally is... but part of reliability engineering is knowing where your weak points are and preventing them from causing problems before it happens. Since the default state is building it yourself, not being able to buy an offline version of the service is no less reliable than the alternative.
Default state is never building it yourself. When you approach new problem, you don't go "ok, let's first start a fire, then melt some silicon to build me some transistors". You always start based on something. And as more stuff is moving to be cloud based services, you'll need to build more and more of that stuff yourself.
Taking it to the extreme - will CPUs in 30 years be cloud connected and require my service provider to work? Would OS be? Or scheduler? Or terminal? Or dynamic linker for libraries? Or IPC framework?
How much of that stuff will companies need to build in the future themselves? It's not like software will get simpler, so they won't need it.
Changing your assumption of "default state" doesn't change what I said.
The point is that systems like this go through various analyses before being built. Reliance on outside services/components is one of those analyses.
Let's say that a critical component is an online service. Someone will do the analysis of what happens when that service goes away. If the outcome is that you can expect to failover to something else with acceptable degradation of performance, then the service might be used. If not, then the choice is find a more reliable service, build it yourself or do without the feature. And those last two choices will themselves be subject to another analysis.
One of the nice things about capitalism is that if there's a profitable gap in products/services, that gap will eventually be filled. All new CPUs need to cloud connected and require a service provider, but there's a big industry that can't deal with that? I guarantee that someone will corner that market and start building CPUs that don't need to be cloud connected and require a service provider. Either that, or sufficiently reliable cloud services, tailored to that market, will appear.
You seem to forget about economy of scale. Sure, void will be filled, but you'll get worse, and more expensive solutions. Economy of scale is ruthless.
And this isn't only talking about software you put on the devices. Developer environment is going to degrade even more and more. It's already bad experience to develop stuff for things that need long term support, and with cloud trends, it'll only get worse, as set of tools that you could possibly use will reduce.
The maintenance and logistics software for the F35 is supposedly implemented with a cloud architecture. Though the project is probably old enough that the cloud hasn't found its way into the flight systems yet...
> i'm surprised that people are surprised by this.
While I'm not surprised per se (seen it enough here and in the industry), it does make me sad and worried about the industry.
This short-term thinking is starting to break everything. How many things sold today depend on some smartphone app? What is the chance that said app will be available or able to run in ten years? Thirty years? I'll bet big money on zero percent chance.
Wouldn't modernizing things here and there not also mean that at some point the entire airplane has to go trough the approval processes again because it is now no longer considered a 747 which in turn also means all personnel need to be certified for the new type?
I once heard, that is the reason why many airplanes still have a "no smoking" light switch in the cockpit although it does not do anything anymore.
There's probably a few very widely depended-on libraries in google3 (internal monorepo) that have been in 'maintenance mode' for 10y or more.
And pretty major pieces that get replaced with nothing breaking noticeably.
A better analogy would be like swapping the engines for electric drive props mid-flight, while other team is replacing most of the wings, but keeping the control surfaces in place.
Now, the cargo service would've been killed, and you'd have 3 mostly equivalent screens to choose from to watch movies during your flight.
> we keep a bunch of old laptops running win 7 and other examples around, hound around for them and spare parts
Maybe I misunderstood something, but do you really need some specific, old hardware to run win 7? I thought you are going to say DOS or something older than win 98.
Why don't you run your old system in a vm running in a new system? That is standard practice at some places. Was there special hardware, not just say usb ports?
Yes. I do some DoD Aerospace work, and we have expensive PCI cards that only work on Windows 7 or XP that are used to talk MIL-1553B to our hardware. So, we've got to have a piece of hardware that can handle both of requirements which can be a pain.
That says more about "the bear", and the overbearing nature of the compliance process, then it does about the wisdom or foolishness of relying on an aging hardware platform like the floppy more generally. Most industries don't deal with that. Maybe if this process had actually proved sufficient to prevent the 737 Max woes, we would pay it more respect?
Arguably the 737 Max disaster was caused by an attempt to side step the regulatory process and get a new plane certified when it shouldn’t have. If the FAA hadn’t been so captured by Boeing, those two planes wouldn’t have crashed.
All in all I can’t understand how one can look at the state of the airline manufacturing in the past 50 years and decide that less regulation is needed. Except for the MAX 8, phenomenal gains in airline safety have been gained over this time period, throwing all that away so that it’s easier to upgrade some old hardware seems incredibly foolish.
The 737 Max grounding cost about $18 billion so far (according tot he Google infobox which knows everything and is never wrong.) The high-end estimates of the value of a statistical human life tend to run about $4-8 million, depending who you ask. The FAA grounding of the Max has 2250 has thus cost enough money to save 2,250-4,500 statistical lives, had the money been spent more wisely elsewhere.
How does your "better" passenger-deaths-per-km measure account for these deaths? (And what is it superior to, exactly?)
You can't point to the grounding of the 737 Max 8 as a reliable indicator of the cost of regulation because:
1. Arguably this is the cost of regulations not being followed properly
2. This is an extra-ordinary circumstance that is costing much more than a regular plane would cost to get certified and fly (see point 1)
3. You are drastically underestimating the cost to the industry both in terms of reduced customer confidence, hull losses (~$100mil an airplane), and increased insurance premiums if we were to continue flying the Max 8.
But honestly, I'm having a really hard time understanding what your point is. Are you asserting that we should just fly the Max 8 and not worry about it? Are you asserting that airplanes aren't safer now? What are you getting at?
> The number of deaths per passenger-mile on commercial airlines in the United States between 2000 and 2010 was about 0.2 deaths per 10 billion passenger-miles. For driving, the rate was 150 per 10 billion vehicle-miles for 2000 : 750 times higher per mile than for flying in a commercial airplane.
> How does your "better" passenger-deaths-per-km measure account for these deaths?
The engine literally exploded, and they made it home via the rest of the plane OK (minus the unfortunate passenger).
In the past this would have cut hydrolics (this happened with a DC10 rear engine exploding) and then losing control. Major props to the pilots and boeing (all SW planes are 737s I believe).
You are severely underestimating how few air disasters we've had lately. The DC10 had an abysmal track record.
Airplane engines literally flying off the plane during takeoff because the airlines got to do whatever they wanted for servicing it instead of the recommended method because maintenance time.
Boeing and Airbus and CRJ/Bombadier/NowAirbus have done a -really- friggin good job in the past 2 decades.
Why the hell would they need to upgrade something as non-essential as a floppy system? To What? Why does it matter if it works? Introducing uncertainty to a system to just make it "new" is spoken like a web dev and not like an aerospace engineer (and I'm a web dev).
In node land you get blasted if you don't stay current (because something will rely on something newer and you'll get upgrade hell'd at once instead of piecemeal).
There are no new versions of GQL that people need to upgrade to. Nor is their version of node going off LTS in 2 years.
I worked in HAWK missiles in the Marine Corps for many years. This doesn’t surprise me one bit. In 1994, Block II launchers were still effectively using vacuum tubes. In fact, I still recall the one that faulted the most, from its label in the FM: relay K-9! Ninety-percent of launcher issues were attributed to that old relic of a tube.
Then, in 1995, Raytheon came out with Block III updates, which replaced the entire trunk filled with hardware (about as crowded as a standard engine bay of a modern car) with about 3 PC graphics cards-sized modules, each with an NSN price tag of $170,000 per (don’t worry, you’re paying for the IP, not the physical cards themselves, which iirc were MIL-spec versions of your standed PCI card from back then).
Made my job as a tech so easy, since the launchers never really broke down much after that, save for a hydraulic leak or two out in Dugway or White Sands during a shoot or Red Flag exercises at Nellis AFB. Didn’t see aliens out there but quite a lot of Soviet gear, which we acquired shortly after the USSR’s downfall. MiGs are really cool and reliable, though pilot/user comfort/convenience was not on their MVP list.
If I've understood Wikipedia correctly, what it's calling "Phase 2" of the Hawk missile program [0] is when some vacuum tubes were replaced.
There are 12 countries (including some rich ones) listed as using the Phase 1 upgrade of the missile, which is presumably still full of vacuum tubes [1]. This is the 30 year old upgrade to a missile developed 60 years ago.
not really - how many software and hardware engineers do you think you need for this? probably minimum 10, maybe 20-30 realistically. At SV salaries (you need the best engineers, right?) that's $9m USD/annum.
You need to ship at least 50 of these devices to break even. To get a proper margin and cover all the other costs (manufacturing, sales, marketing, compliance, accounting, yada), you're probably going to need to create and sell a couple hundred, every year.
One other thing is that launchers and other boxes that control weapons are DAL-A equivalent, so you have to be rigorous about your requirements and testing to ensure that a missile never accidentally fires. This drives up development costs as well, since you have to do a lot more work to verify and validate the system.
It depends what you mean by "SV salaries" but defense contractor developers can make a lot of money, especially compared to other software jobs in the NOVA/Maryland area (which are not paid nearly as well as SV).
So, what's the problem? Updating 30-year-old gear with media from its era seems to make sense.
If they were really wedded to digital media and needed to bridge that gap, Sony used to make a floppy disk that you could jam a memory stick into and it would read in a normal 3½ inch floppy drive. Very cool gadget.
Frankly, provided you have error checking logic and don't store them next to a magnet... floppy disks are pretty damn bulletproof. I've had way more issues per-use reading a thumb drive or a CD/DVD-ROM than I ever did reading floppy disks.
Really? I'm not doubting you, but I'm surprised. I only used them up until I was maybe 10 or 12 years old, but I still vividly remember often having to go through a couple of floppies from my drawer to find one that was working. And yelling at my little brother for putting a bad one back in the drawer.
Are they really that robust? Was I just storing them stupidly maybe? Or maybe it was because all the ones we had were used ones from work.
Not very. There's significant wear and tear from the drive head, to the point that you could see it with the naked eye after a while.
If you are not using them frequently, storing under ideal conditions, than maybe. I've been able to read floppies a decade after they were written. Not for long though. Drive required cleaning afterwards too.
I have similar memories from around the time when USB sticks started gaining popularity. I think floppy disk manufacturers started slacking off on QA through the last few years of large-scale manufacturing. They certainly didn't used to be that bad.
The final years of 3.5" floppy manufacture were bad. I think the quality was tailing off from the mid nineties. But it could equally be poor quality of the drive manufacture as well.
Certainly 5.25" floppies from the late 80s and early 90s were nearly bulletproof in my experience. 1.2MB was a bit flakier than the 360KB though. All were still perfectly readable 20 years later, though at this point they all got thrown in the bin due to their obsolescence!
Yep. Only a single datapoint, but I've had more issues with flash drives and USB sticks than I've ever had with floppies.
CDRs are next level in terms of unreliability. Last year I discovered that almost none of the CDRs I'd burned in the early to mid noughties remain readable: simply had to destroy them.
I found a box of old floppies... the media had become unglued from the metal center ring. Maybe other brands use better glue to make them bulletproof, these were not.
My experience is just the opposite. Have had to replace more floppy drives than I can count. Used to work in a dusty environment, but that alone doesn't explain the failure rate.
While this probably wouldn't pass muster with whoever certifies the 747's avionics, over in the retrocomputing world the solution to "It only uses floppies" has been the cheap Gotek floppy emulators that read from a USB stick running this free firmware: https://github.com/keirf/FlashFloppy
Agreed. Not for avionics, but I cannot overstate how much of an improvement the Gotek/Lotharek/various other Floppy Disk/scsi to SD solutions are over finding NOS/still working storage media from that era.
Ive a couple of old samplers from Emu and Ensoniq that I can continue using and not worrying (as much) about data loss and storage.
It wouldn't necessarily be a certification issue because updates to avionics bundles already require a checksumming/validation step. At worst, if it doesn't work you'd have to try again. However, adding in the USB support on some of these older devices might be a hassle.
We really should be updating our planes from S3 and running the entire fleet on Kubernetes with Kafka to handle all the Airline tickets and Redis to make it all go fast.
Not surprising at all, and not really a problem either provided it works.
More modern aircraft use things like USB sticks but often with old file formats and they can’t use a stick bigger than 2GB (actually hard to find if you want to buy one). Aviation engineering vastly prefers “old but works” over “new and fancy” and this article is just one detailed example of that.
I get why prefer old but works over new and fancy, but what about new and works? They could trial new technology for five or ten years in parallel with the old before switching gaining both the stability of old and proven and the future-proof-ness of "new and we think it will stick but it might not". The reason why it isn't done this way is probably cost, but at what point will the difficulty of sourcing the old tech and people who know how to use it become the more expensive option?
You can still buy new, still shrinkwrapped, recent production floppy disks and new drives. I'd imagine if you're supplying parts for these, a warehouse with a stack of known-to-work floppy disk drives isn't much of an expense and certainly not difficult.
Even if it became a problem, you reasonably have the margins to ask a manufacturer to setup an assembly line and run a new batch just for you - the only downside is that you're likely spending a lot of warehouse space to house the new parts.
I remember reading a news story ~4 (or more?) years ago that the last manufacturer of floppy disks stopped making them. I’m not surprised to learn there’s still plenty in circulation, but I’m a little confused by “recent production”, unless my memory is just wrong...
If you're spending $30mm+ on an airplane, getting specialized media for it is the least of your worries. Also... floppies work decently well. They're not fast, but they work. It's not like your data transfer speeds will improve with thumb drives either... the hardware doing the reading isn't going to be very fast.
"New and works" is used in aircraft that come off the production line today; just look at the flight deck of an A350. New avionics start out in the iPads of GA pilots, then get that 5 to 10 years proving in the flight decks of business jets, finally making it into the cockpits of jetliners.
I'm fairly confident that newer aircraft are using newer, but works, technology. There's no reason to update the hardware on the 747 to use that technology, though. It'll be expensive to certify and retrofit.
Yes. Usually it is a FAT/FAT32/NTFS formatting issue.
Although the most annoying issue is usually related to SD cards. Most SD Cards these days are usually "SDHC" or "SDXC" cards and formatting them to a 2GB partition doesn't actually work.
At one point in my career, I was working on maintenance software for the US Air Force's C-130 Cargo plane. Floppies weren't used to update the flight software (the Mission Computers didn't have floppy drives). A ruggedized portable computer was used to load the Mission Computer software over a wire connection. The software doing the loading was held to the same MIL-Spec standards as the flight software itself, and we spent a lot of time convincing the reviewers that the checksums used to verify the integrity of the load were sufficient to the task.
If the software doing the load is performing its integrity checks to a sufficiently high standard, then I don't see why using a 3.5" floppy disk would be a problem.
So? There's nothing wrong with diskettes as a medium. They're not used much any more, but they work OK.
F-16s still use PCMCIA cards to load combat flight plans. Obsolete, but small and reliable. Also big enough to handle on a flight line while wearing gloves. An SD card would be too small. A USB stick might accidentally get plugged into something it shouldn't be plugged into.
Note that the article covers the 747-400, which first flew in 1988. Using 3.5" floppies for updates made sense then, and aircraft avionics tend not to be updated unless absolutely necessary.
The Panavia Tornado fighter jet famously used cassette tapes for mission data. I guess aircraft are a product of their time and because of stringent safety requirements why try to update something if it works fine?
"...Then there was the computing power on the aircraft—or lack thereof. It was a Commodore 64 with wings on it ...For example: the mission computer loaded off of magnetic tape.
That magnetic-tape computer had so little memory that its crew had to switch programs depending on what the jet was doing at the moment—the RIO would hit a switch to bring up the bombing program, and then after the bomb-dropping ended, they’d reload the air-to-air program"
The F14 actually had a neat processor, with an architecture which remained classified for a long time (arguably far too long at the end, but it was plainly justified at the beginning)
It was very old so, yes, I'm sure it had plenty of limitation though.
The headline is misleading. According to the story text, the floppy is used to load a new navigation database, which is important to be sure but not a critical software update.
Navigation data is important, which is why it's required to be refreshed within 28 days (this was a big worry during the recent Garmin outage BTW), but whether it's critical depends on often domain-specific definitions. AFAIK it doesn't meet that standard by either software or aviation standards. Also, it's definitely not software, so "critical software updates" is still incorrect.
On an airliner that can land in cat III approaches (ultra low visibility down below 100') then this data is critical since it's used in automated systems to help land the plane.
It's going to be required to fly legally, without a waiver. But in terms of the engineering development assurance required, typically it is more 'critical' than radios and less so than flight controls, engine controls or displays. Of course this depends on the safety analysis performed for the individual aircraft and intended operations.
No no, the old airplanes have a binder full of floppies so that any time the plane has wheels on ground, you can reload one of the critical systems without waiting for someone to fly in with replacements.
By the 787 they were working to replace this all with code signing.
ETA: This bears repeating: aircraft have interlocks. There is a sensor that tells you that the plane is parked (wheels on ground) and there are connections, maintenance, and administrative changes that cannot be made unless this is the case.
Nobody is going replace the maps with Rick Astley somewhere over the Pacific at 3 am.
When 3.5" floppies (stiffies) were introduced, the big selling points were that (a) they could fit in a shirt pocket and (2) you could toss them across the room and they'd still work.
At my first job, I kept a 5¼" floppy with "only copy of important data" written on the label hanging off my filing cabinet with a magnet.
They were before my time, but I had an old drive I "examined" (destroyed) as a kid. It was unclear to me how such a large thing could hold so little memory.
When I worked for a major pharma company in the mid-to-late 2000s, their entire security system (IE, the door badge ACLs) was run on an old vaxstation that had its own full rack. It worked, they said.
I work on aircraft that up until last year received updates via ZIP DISK. Do you know how hard it is to find a working ZIP disk and/or ZIP drive?
Luckily we convinced the owner to update their avionics and now it uses... CDs? DVDs? A laptop? I honestly don't know. Something that isn't ZIP disks. We also have aircraft that need floppy disks.
The article said the floppy drive is kept behind a locked panel. The article doesn't mention if the updates fit on a single floppy or a stack of 20 floppies. I don't see a fundamental problem as long as the data has checksums to make sure that it transferred successfully. I used to get tons of errors on floppy disks transferring data back in the 90's using Sun workstations and PCs. I started making my own checksums to make sure my transfers were correct.
I got so much exercise trying to install Slackware from >20 floppies. Disk 5 has read errors. go copy another, start over from disk 1. Disk 8 has a read error.
(By the time I was done I didn't have enough disks, so I had to go to the lab in the middle)
I installed Slackware 2.1 with kernel 1.1.59 in the fall of 1994.
I only had about 15 floppies between me and my roommate. I remember getting the "a" series of disks and then the "d" series for development and so on. I had to run back and forth to the computer lab about 5 times over the weekend.
The bigger story in the article is how little security review the software on these planes get
> "Aircraft themselves are really expensive beasts, you know," said Lomas as he filmed inside the big Boeing. "Even if you had all the will in the world, airlines and manufacturers won't just let you pentest an aircraft because [they] don't know what state you're going to leave it in."
The physical floppies use the same chain of custody that any other part of the system use. Every floppy has essentially been signed off dozens of times before it ever sees the insides of an airplane, and there is nowhere between the manufacturer and a flying plane where there isn't a person who is officially in charge of it.
From what I understood, there is (was) a real danger of a part that was used in a stress test ending up in a bin full of spares. So every 'part' has an identifier, responsible parties, and a tagging system that keeps the streams from ever crossing. A floppy is physical, so they just did the same thing.
Imagine trying to convince a bunch of people who have always ever done things physically to use electronic distribution.
The good news is that any new avionics system is going to have the ability for electronic distribution. Mostly due to reduced cost (cheaper than mailing out disks/CDs/DVDs) and better ability to correct any bad updates that are released.
That logic is baffling. If it's so easy to render a plane unsafe that they're frightened of letting someone pentest it, surely that would indicate a major problem that it's much better to find out about on your own terms?
I cannot remember where I saw it a few days ago. They basically just use an emulator and a fake floppy disk, just like people could play cd's over a cassette player.
I assume they don't have to go through certification for the loading device(the floppy drive), just the process of loading data instead (through the emulator)
The software that really matters, like really matters (not talking even about something like Google Search or Gmail)... is usually like this, since it's built to be almost never changed, since changing it is so high risk that it's almost never worth the cost.
i work for aerospace, and this is fairly typical -- albeit not floppy disk examples, but we keep a bunch of old laptops running win 7 and other examples around, hound around for them and spare parts. these machines are off the network, etc.
these systems were developed 20+ years ago and per contract the a manufacture is obligated to maintain them for the service life, so unless these are obsoleted these are to last 20-30+ years.
the costs associated of porting all tools from win 7 to a newer system and re-verifying 50K+ test cases to do a similarity analysis run into astronomical in terms of $ and months (years) of work. no one really wants to poke that bear so you have situations like these.