[snickerbockers]

jesus christ, i dont think ive ever seen an article that beats around the bush for as long as this one does before finally getting to the point.

anyways, for those who don't have the patience, the title is misleading. it's just some old software from the 90s. It's only ancient if you're one of those people who completely rewrites their entire code base from the ground up every two years because to pad out your resume with whatever bullshit new "framework" is in vogue. Contrary to popular belief you actually can just keep using the same software indefinitely, it doesn't degrade with age, and for the most part the hardware lasts pretty long too as long as you take care of it (with a few exceptions like optical drives and SSDs).

[hn_throwaway_99]

Agreed. The older I get, the saltier I get when I read anything that refers to something from the 90s as "ancient".

[KineticLensman]

> Agreed. The older I get, the saltier I get when I read anything that refers to something from the 90s as "ancient"

As someone who started programming in 1980, I feel your pain. My oldest spreadsheet goes back to 1995.

[justinator]

There's a little more to it. If your original team retires because of old age, that's a lot of wisdom lost. Not everyone wants to learn COBOL to keep planes in the air and the IRS running, imagine needing to figure out the low level code on something millions of miles away with half the hardware broken, the battery cracked and leaking – and if the software update doesn't work, the entire mission is over?

It's altogether amazing.

[ericbarrett]

COBOL is really quite straightforward and readable. I don't think a developer who's already familiar with a modern language or two would have a hard time picking it up. The system it's operating is domain-specific knowledge anyway, and would be something a newcomer would have to learn (or be familiar with) regardless of language.

[justinator]

>I don't think a developer who's already familiar with a modern language or two would have a hard time picking it up.

You're probably correct, but it's more about if they would want to pick up a language that has no future, except maintenance of already existing systems. (see: Perl).

[deepspace]

The article calls software from the 90s "old". Nobody used COBOL for mission-critical software at that time. There is embedded software I wrote in the 80s and 90s still running in the field, mostly written in C.

[justinator]

I didn't wrote that COBOL was used in aerospace, but used it as an example in different industries.

[JohnFen]

> Not everyone wants to learn COBOL to keep planes in the air and the IRS running

But there's excellent money in being a COBOL programmer. Some might be interested in that.

[peraspera]

Not to mention that they confuse RAM with storage. The iPhone 14 certainly doesn't have a minimum of 128 GB of RAM.

[CoastalCoder]

Depending on context and the audience, it could be fair to use "RAM" to refer to SSD storage.

SSDs are random access, just not volatile like DRAM.

[ComputerGuru]

The only context in which the technical difference between memory and disk can be glossed over is one where the audience is made of laypersons that wouldn’t understand the first thing about seekable vs random-access memory in the first place.

A tech-illiterate author/editor is the much more plausible explanation.

[jychang]

On the other hand, a modern SSD is probably faster than RAM on a spaceship from the 90s. (Don’t quote me on this, I didn’t double check).

All of a sudden I had an urge to get MS-DOS to run with a SSD as memory. Unfortunately I know DOS can’t address 1TB of memory, but the mental image of it is hilarious.

[thamer]

I'm not sure you'll see this, but just in case: the Apollo Guidance Computer used RAM called "core rope memory", and the cycle time was 11.7 microseconds[1]. This isn't too far off from what the best SSDs can achieve for random reads at 8-10 microseconds[2], although these numbers are likely for their minimum block size of 512 bytes.

[1] https://history.nasa.gov/afj/compessay.html

[2] https://www.tomshardware.com/news/micron-finally-rolls-3d-xp...

[mosselman]

I find one of the subtitles for one of the images strangely worded too:

“The Voyager space missions were maintained by technology that would today be artefacts in a museum”

The technology either is or isn’t in a museum right now. Why say “would today be”. If it is you can say “technology that by now you can see in a museum” and if it isn’t you could say “expect to be in a museum”.

[dang]

Ok, I've taken the ancient technology out and replaced it with old software in the title above. Thanks!

[weinzierl]

The article is bad but the premise is not wrong. The things that fly and a lot of the things that stay on the ground are analyzed with NASTRAN whose solver kernel dates back to 1964. At its heart it is still the old FORTRAN code because reproducibility is king.

[JohnFen]

> it's just some old software from the 90s.

What nonsense. the 90s is recent, not ancient.

[wuming2]

It may be true with embedded applications or with Windows. Not on a Mac.

[cryptoz]

Software does degrade with age, though. Simply the fact that vulnerabilities are found over time means that our understanding of a piece of software and how it works changes. But it's not just vulnerabilities being found, it's protocols used that may be unsupported etc. That change is a kind of a rot like people call 'bit rot' but it's a specific software rot that does happen. Systems are complicated.

[kwhitefoot]

Most software used not to be connected to the outside world. It wasn't vulnerable at all unless the attacker already had control of the host.

In the thirty years I spent developing software I spent hardly any time on anything that was accessible through the network and I'm confident that I'm not the only one. The embedded control software that I wrote for 6502s would still work today and would be completely invulnerable to attacks other than from someone standing right in front of the machine pushing buttons.

Of course now that everything has to be networked so that your fridge can advertise special offers to you the situation is changing for the worse.

[z3t4]

An example is SSL root certificates, which expire by design. Also ABI. But if you use containers or virtual machines you can basically have a program run forever.

[arter4]

You can, but you shouldn't, because at some point you should patch the vulnerabilities you inevitably find on any non-trivial piece of code after a while.

[bombcar]

Certain code can run with bugs forever, even vulnerabilities, because it will never interact with anything (see the famous "the missile" bug - a counter would overflow at some point, but by then the warhead would have detonated, so who cares?).

[JohnFen]

Sure, but none of that applies to non-networked embedded systems.

[deterministic]

Brand new software made yesterday is full of bugs and will kill or maim you if you try to use it for safety critical systems. I trust 10+ years old code that has been proven in combat. Not crappy new code written by some arrogant young “Ninja” who has no clue on how little he/she/it knows.