4 ms·

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 d

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

wink 3y ago
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 3y ago
  Check mbsybc + msmtp + Mutt.
generalizations 3y ago
> 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 3y ago
  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.
a1o 3y ago
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 3y ago
  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 3y ago
    > 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 3y ago
  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.
whateveryousayw 3y ago
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.
- bruce511 3y ago
  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.
- Clamchop 3y ago
  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.
nerdponx 3y ago
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.
1vuio0pswjnm7 3y ago
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.

wink 3y ago

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 3y ago
Check mbsybc + msmtp + Mutt.

generalizations 3y ago

> 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 3y ago
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.

a1o 3y ago

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 3y ago
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 3y ago
  > 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 3y ago
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.

whateveryousayw 3y ago

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.

bruce511 3y ago
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.
Clamchop 3y ago
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.

nerdponx 3y ago

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.

1vuio0pswjnm7 3y ago

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.