[bruce511]

Finished Software is a beautiful thing, and personally I use a bunch of software I wrote back in the 90's and after.

BUT (and it's a fairly big But) software does not work in a vacuum. If the software does any interactions with other software, think any kind of networking like email, ftp or whatever, think printing, and so on, then you should expect it to stop working (in those areas at least) at some point.

All network protocols get tweaked from time to time - TLS code changes - Authentication schemes change, I could go on but you get the point.

I've lost count of the number of people who complain to me "but it worked yesterday" - and sure it did - BUT the "world changed and you didn't keep up."

I love finished software - but not all (categories of) software will run forever. Once there is other software involved, then sooner or later it'll likely "stop".

[whateveryousayw]

For the reason you mentioned, there is no such thing as finished software, because no software runs forever without maintenance: nothing works in a vacuum. You're either at the mercy of an API, an operating system, a BIOS, etc.

The amusing thing is that for game development, the most stable target platform is old proprietary video game consoles like the Genesis and Neo Geo simply because there are dozens of emulators for them that run on hundreds of platforms. "Write once, run anywhere" is more true if you program a new Genesis game than make a native cross platform PC game.

Make a PC game, and there's a decent chance it'll stop working after a couple of decades (most Win95 games are already dodgy). People will be making Neo Geo emulators after you're dead. If you make a Neo Geo game, it's going to run on virtually every computer for a very long time.

The real power of it is that it gives you the ability to latch onto the fame of (and interest in) a popular platform. Even if you make an open source game, the problem is that if you didn't program Doom, there's a good chance that there isn't going to be enough interest in it for large groups of people to maintain it over long periods of time.

All things will break in time, though. Eventually, people will probably lose interest in maintaining emulators for arcane systems like that, and your software will stop working then.

[Clamchop]

You can spin up Windows 95 and its games today!

But, for a long while now, the forecast has been looking increasingly grim for emulation and software preservation.

That said, if you're targeting the performance envelope of 1990s games, there are options without resorting to anything so esoteric as emulated consoles.

[bruce511]

Sure nothing runs "forever" but on Windows it's not uncommon to use utilities compiled for windows 95 or so. Basically anything 32 bit will still run. I use a bunch of command line, and windows-based tools from that era in my daily work-flow. (Hello GREP).

Once it's interacting with more than just Windows though then things get less rosy.

[wink]

That's more of an argument for decoupling though. Why can't I have a local permanently-updated "fetch mails via IMAP"-tool and then a mostly dumb GUI mail client that does not care about cipher changes for 10 years?

If someone's about to comment with fetchmail, shoo :P

I've never seen that work properly on Windows, it's not end user friendly and I'm not sure how to put "decoupling" better - all I'm saying is that for how email works at least, no, Thunderbird wouldn't necessarily need the means to talk to servers, something local via socket/named pipe/filesystem might be enough - but this would mean more of a paradigm shift and yes, it would maybe also be bad for end-to-end crypto (depends how you define the end, it's still your machine...)

[anthk]

Check mbsybc + msmtp + Mutt.

[a1o]

Not only that, imagine you release something for some Mac, and it goes from PowerPC to Intel, now you adapt your OpenGL code in OSX, now OSX doesn't work in 32-bit, now you need to use Cocoa, Quartz, Uikit or whatever. Hey, we now named it macOS, what about moving your OpenGL to Metal? And we are not x86 now, we are Apple Silicon. This is just one platform, there are several that changed and required adaptation in the software. Some also died, so if produced great software for Silicon Graphics, Sparc, Amiga or whatever, well, you will have to update the software to port over to somewhere too.

[ryandrake]

Unpopular opinion, but software should not have to keep up with this treadmill. Especially since the treadmill is a deliberate choice the OS vendor is making, and not some fundamental attribute of software. Bits don't tend to simply rot. The foundation they are planted on deliberately gets broken. The vendor could choose to allow backwards compatibility, but often chooses not to.

Sorry, but when I write a program in 2010, I kind of do expect it to still work on the exact same hardware in 2020. I don't think that's an unreasonable expectation.

[jolux]

> The vendor could choose to allow backwards compatibility, but often chooses not to.

This too entails a tradeoff: either the old software sits around in the system collecting defects, or it ends up supported indefinitely and the amount of work required to cut a new OS release increases without bound.

> Sorry, but when I write a program in 2010, I kind of do expect it to still work on the exact same hardware in 2020. I don't think that's an unreasonable expectation.

Unreasonable compared to what? In the abstract it’s not unreasonable but computers are quite an unreasonable environment to begin with. Their capabilities change dramatically every few years, and computers on the internet especially have to withstand essentially constant attempts at intrusion and abuse.

[mid-kid]

Apple is a particularly bad example of this kind of churn. They have an iron grip on the entire ecosystem and can get away with it, but you have to wonder at what cost.

[seec]

I believe they lose the goodwill of their users over time. At some point they get pissed off and move on to a cheaper more stable option. I am a historical mac user (started using system 9) and I am disillusioned about Apple. They change things too much, too often, for what are generally very litte benefits at a tremendous cost.

Everybody is over the moon about Apple Silicon, but so far what I see is that we completely lost Windows/other systems capabilities, got even more uncompetitive GPUs than they used to be (if losing windows compatibility wasn't enough, they had to make sure you couldn't play a single game properly) and price and skyrocketed. For what? A better battery life, and a lot of marketing on how things are supposedly faster but outside of video processing they are definitely not if you make equivalent pricing comparison. Power is cheap and ubiquitous, mobile high-performance computing makes no sense at all; external batteries are cheap if they are really needed.

And now you have to deal with annoying software incompatibility, updates of all kinds and re-purchasing stuff that was working just fine before. Some software didn't even get updated and will never because companies have decided it wasn't worth the trouble (they are right).

Sometimes I see some people complain about Windows updates and whatnot. Well, compared to Apple shenanigans, I really do not mind them. I like not even registering on the annoyance scale compared to Apple bullshit.

[0x000xca0xfe]

Obviously at the cost of having a weaker gaming ecosystem than Linux.

They showed off the powerful GPU of their new M3 yesterday and chose... Myst. Now that is almost comical.

[generalizations]

> If the software does any interactions with other software, think any kind of networking like email, ftp or whatever, think printing, and so on, then you should expect it to stop working (in those areas at least) at some point.

This is the beauty of line-delineated (ha) text-based pipes. I wonder if some of those unix tools would be considered in any sense 'finished'.

[nradov]

Text based pipes only work well for a very limited set of use cases. In the real world we often have to deal with binary data, objects, and structured documents.

[1vuio0pswjnm7]

When I use a TLS forward proxy, networking software from the 90's works fine. For example, I still use original netcat from 1996 every day, as well as tcpclient from 2000.

Personally, I actually trust the "TLS code" in the proxy, e.g., to be up-to-date and correct, more than I trust the "TLS code" in today's "apps". It's easier to update the proxy, a single program, at the user's discretion, than to worry many different applications, all expected to be free of mistakes and to update prudently themselves.

With the proxy, it's open source so I can do a diff with the version I am using before deciding whether to compile and use a new version.

[nerdponx]

I think this is a big part of why some people complain about programming languages and environments seeming to tend towards shorter periods of backward compatibility.

It's frustrating when a piece of software or a library has been functionally "finished" for a long time, but still periodically needs maintenance and updating to accommodate changes that really have nothing to do with the purpose of the program itself. this is probably the one aspect of the Python2->3 complaint that I sympathize with.