[deleted]
Dealing with abandonware (2024)
11–20 of 55 posts
Re: Dealing with abandonware (2024)
#12Kinda off topic but related. But is it realistic these days to just expect software to write once and run forever? I am a TypeScript/Frontend guy by trade, but I always admire languages like Go. It seems like a simple language that I can write once and maintain forever or once in a blue moon. Everytime I want to write something in TypeScript and then I pull bunch of crazy dependencies, I began to question if it is wo…
I'd reasonably expect software to run forever insofar as the environment it's run in doesn't change. Essentially, no OS or dependency updates - network is inevitably going to get broken. Anecdata: My Wii (2006) console has had a few hardware issues I've fixed, but the software is just as responsive as a decade ago (though many external networks/servers have shut down). Homebrew community is very much alive and has ex…
I was thinking to defer to the compiler to make things stable. i.e, Go or JavaScript virtual machine should just run forever and able to decide with OS updates.
On the frontend world, the browser so far has been super reliable in maintaining backwards compatibility of HTML, CSS and JS for years and years.
Re: Dealing with abandonware (2024)
#13Earlier quoted context omitted.
Easier said than done. - It's risk for them with basically no upside. - Someone at their company needs to do a deep-dive into the code and verify that there aren't licensed third-party libraries and possibly remove them. Even companies that genuinely want to open source software that they've acquired may spend a year doing this sort of due diligence.
Well, or they could release a patch that simply nerfs the license check on the binary. No risk in terms of lost profits, for software they no longer sell.
That assumes the (a) the source is still available (b) the build environment is still available and working, (c) a staff member is still available that understands the system and/or (d) the time to figure it out and rebuild, test, and create the binary diff/patch ....
Re: Dealing with abandonware (2024)
#14Kinda off topic but related. But is it realistic these days to just expect software to write once and run forever? I am a TypeScript/Frontend guy by trade, but I always admire languages like Go. It seems like a simple language that I can write once and maintain forever or once in a blue moon. Everytime I want to write something in TypeScript and then I pull bunch of crazy dependencies, I began to question if it is wo…
If you use something like Win32 it probably will remain usable into the far future, especially with WINE and/or VMs. I have 30+ year old utilities that were originally written for Win95 but still work on Win11.
Re: Dealing with abandonware (2024)
#15Kinda off topic but related. But is it realistic these days to just expect software to write once and run forever? I am a TypeScript/Frontend guy by trade, but I always admire languages like Go. It seems like a simple language that I can write once and maintain forever or once in a blue moon. Everytime I want to write something in TypeScript and then I pull bunch of crazy dependencies, I began to question if it is wo…
You can get close. I have personal app and production systems in past jobs that are just running along year after year doing what they were designed to.
You can never escape security patches, but your theory of limiting to a free stable dependencies usually works really well for me.
Re: Dealing with abandonware (2024)
#16Kinda off topic but related. But is it realistic these days to just expect software to write once and run forever? I am a TypeScript/Frontend guy by trade, but I always admire languages like Go. It seems like a simple language that I can write once and maintain forever or once in a blue moon. Everytime I want to write something in TypeScript and then I pull bunch of crazy dependencies, I began to question if it is wo…
I've used plenty of Common Lisp code from 30 even 40 years ago without issue.
Re: Dealing with abandonware (2024)
#17Earlier quoted context omitted.
I'd reasonably expect software to run forever insofar as the environment it's run in doesn't change. Essentially, no OS or dependency updates - network is inevitably going to get broken. Anecdata: My Wii (2006) console has had a few hardware issues I've fixed, but the software is just as responsive as a decade ago (though many external networks/servers have shut down). Homebrew community is very much alive and has ex…
I was thinking to defer to the compiler to make things stable. i.e, Go or JavaScript virtual machine should just run forever and able to decide with OS updates. On the frontend world, the browser so far has been super reliable in maintaining backwards compatibility of HTML, CSS and JS for years and years.
Unix shell script also more or less reached a stable state. It's even optional to target Bash rather than just shell.
Re: Dealing with abandonware (2024)
#18You can go to this effort to get it to make the right magic number .... or just find the place where it gets tested and replace the conditional branch with a unconditional branch (or a no-op)
Having said that I once wrote 68k code that was an executable copyright message, and other code that if it discovered it wasn't running on an authorised machine logged to a known port, sent an email, unlinked the binary, queued "sudo reboot", killed the parent process and then exited (all the authorised machines were mine, running a bespoke kernel)
Re: Dealing with abandonware (2024)
#19Earlier quoted context omitted.
Well, or they could release a patch that simply nerfs the license check on the binary. No risk in terms of lost profits, for software they no longer sell.
That assumes the (a) the source is still available (b) the build environment is still available and working, (c) a staff member is still available that understands the system and/or (d) the time to figure it out and rebuild, test, and create the binary diff/patch ....
Well, yeah. The point was that there are changes that could be made, without having to make it possible for everyone else to build, that would enable continued binary support.
Re: Dealing with abandonware (2024)
#20That's real abandonware. These days people gripe and moan about "abandonware" when they have the source code.
Oh shit, no new commit in 8 months! Abandonware!