When I become king of the United Continents, I will make a new rule:
If you don't publish high-quality updates for your software for one year, it will become open source automatically.
Mm. I think "any" update would be sufficient for 95% of cases, doesn't have to be high-quality.
Even if it's just the copyright date changing at least once per year, that tells you one specific named entity is claiming to care about it: when nobody does even that much, everyone automatically has the right to do whatever they want with the software.
Which reminds me, I need to update the copyright date on my website…
I would first search keygen/crack archives to see if some famous scene group had already done the needful long ago, although for software as obscure as this, it's less likely. Then again, I've seen some very obscure software ("there's an app for that!?") when browsing those before.
You 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)
Why patch the binary to get the correct "system identity" value, to match the license/serial-key you've got? Instead patch the serial-check out of the software entirely.
The problem with that software title is caused by a hostile licensing system it uses. It relies on an offline form of online activation where the activation key is tied to your installation ID, which in turn depends on OS/hardware identifier of your computer. This is an overkill IMO.
I cannot imagine people working with ceramic tiles cracking a static licensing system. Yes, they can overshare license keys but realistically this does not happen too often, and there are non-invasive ways to circumvent this.
I've worked on parts of a training platform for a specific professional group... There's literally been widespread hacks to bypass the need to watch mandated training material. You'd be surprised the efforts people will go through to get to/through something they need.
Kinda 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 worth it? These days I am just pulling React, TypeScript, and just do CSS. If I need a dependency I'll try to just code it from scratch with LLM. Is it realistic to expect, React, TypeScript to be maintenance free forever? Since those are basically just abstraction on top of HTML/JS/CSS which are rock solid.
Ideally the home-baked software that I build will be just using very simple technologies, and I can just vibe/LLM code all the dependencies, or worst case just vendor it, and update it once a year or longer.
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.
> is it realistic these days to just expect software to write once and run forever?
Yes, but you have to put a bit of effort to make it so. For example, if you write your software as a ROM for an early game console (SNES/GBA/etc.), you can probably expect it to run for a very long time, as there will likely be people who want to play Final Fantasy 6 and Pokémon Silver for as long as computers are around.
That's one extreme, but you don't have to go that far. I have some HTML/CSS/JS projects (meant to run locally) from the 2000s that still work totally fine today. Same for Python code from 2010, etc. I wouldn't be surprised if those still worked just fine 50 years from now.
All I do is write code that is meant to run locally first, with very minimal dependencies, only choosing to use conservative/proven technologies.
DOSBox! Super stable APIs that will never change. And it self-hosts compilers and editors (up to latest versions of Emacs and at least versions of vim from earlier this century) so anywhere your code can run you can also modify and recompile it.
(In practice I edit my code outside of DOSBox, and sometimes I use cross-compilers, but it is good to know that there is a fallback.)
> there will likely be people who want to play Final Fantasy 6 and Pokémon Silver for as long as computers are around
Is Final Fantasy 6 seeing a lot on new players today? Old games are played more by the people who enjoyed them when they were new. Even the landmark games are easily forgotten and younger players will never bother when they have so many modern choices.
The modern choices are accompanied by ads and gambling, to the point that it wouldn't be surprising if Final Fantasy 6 was seeing an uptick. Go enjoy your "modern" games all you like, but it doesn't always matter if a games community is growing, especially if it's not one requiring connectivity to blast ads and skins at people.
The Titan submersible implosion features a lot on HN, and almost nobody here built such a contraption, or took one to the bottom of the ocean, or imploded. Naming a gaming storefront which may sell an old game doesn't answer the question whether young people want to play it.
My reasonable baseline assumption is that almost no young player is going to jump to play a 30+ year old game. I'll be generous here and not name things like Frogger or worse, The Oregon Trail. But give a kid who has seen modern games a copy of Diablo, or SimCity 2000, or even newer things like or GoldenEye 007 or System Shock and watch the "excitement". And these are the heavy hitters.
A lot of these oldies didn't age well even for the people who loved them way back when. It's hard to get young players excited about them. Very few oldies could stand on their own today.
Some software does. If you've worked on SCADA gear it's expected to go into production and then run for 20-30 years without being patched once a month, or, actually, ever.
Someone once asked the author of an at the time widely-used security utility why it hadn't been updated since 1996, and whether it was abandonware. His response: "No, some people just get it right the first time". Just had a quick check and there's a single CVE for it from 25 years ago, possibly from a third-party mod rather than the original code.
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 expanded its utility.
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.
> But is it realistic these days to just expect software to write once and run forever?
From an engineering perspective, yes.
From the current mindset in SW development (reinventing the wheel every couple of years) no.
Almost all current SW is throw away software.
For most of it you need a particular version of an OS, particular versions of libraries and a particular planet alignment, just to be able to run it.
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.
I was a beta tester for Freehand/MX, and used Freehand and Altsys Virtuoso for decades before that --- it still running on Windows is why I still use Windows, and I despair of what I will use for vector drawing when it stops running.
None of the Inkscape devs are invested in Freehand's keyboard shortcuts and working techniques, Graphite doesn't even work with a stylus, Cenon is clunky beyond words and hasn't been upgraded in decades last I checked, Krita is pixel-oriented, and none of the note-taking programs really work for technical drawing/vector editing....
You seem to be describing how the web dev worked after JQuery but before React. It wasn’t prettier than now.
I agree that the wider NPM ecosystem is a morass of slop and that is technical debt for anyone who wanders into that minefield. But the solution isn’t to assume that there are no bad / unmaintained GoLang libraries. It’s to realize that maintenance, quality, and sustainability need to be first class attributes of every library you choose to allow your project to depend on.
Your proposal will yield lots of LLM near-slop (basically code that works given the original prompt requirements, but will fail to continue working well once some requirement changes, some original assumption is violated, some browser changes are implemented.
Ultimately, the sustainable solution is to have a subset of NPM libraries be extremely high quality, vetted via robust tests and security audits, and are visibly different than the average slop on NPM. Basically a very visible delineation between untrustworthy code and very trustworthy code. Then you should be able to tell the LLM to use only dependencies from that vetted subset.
I'm not sure if it's abandon ware but I found a gist which attempted to get pictures from this Korean Kindergarten app for backup which we also use.
I tried it and it only half worked and you had to copy a cookie out of the browser which would expire after a couple of days.
I took it and extended it added a login with selenium or what it is called and now I can run it daily and get those pictures out and into my immich. Instance.
I have a tangentially-related question. I've been using Novagraph Chartist since the Windows 3.1 days back when I was 17 (I'm now climbing 50!). It seems that the original company behind this has vanished, I've asked for support, but no joy there, I hope the author is still alive. I'm on Chartist 5.2. It needed online activation towards the end of its life.
Whilst in these modern days of hi-DPI screens and anti-aliased lines, I still love using Chartist - I know all of the keyboard shortcuts and I can use it to create a diagram faster than using anything else.
>I use a MacBook, and this application is Windows only, so executing it is out of the question.
This is where things went off the rails. Choosing hard paths should be done when you're exploring, and never when you're fixing a business issue. Why didn't they just try it out in a VM or even a mega cheap VPS? Why is doing it the easiest way imaginable completely out of the question?? I have no empathy for this kind of pain.
To be fair, GitHub code rots much faster these days. I would assume anything with a specific job to do (not games) that is untouched for 8 months is circling the drain and expiring in another 8 months.
reminds me of my own software I created and was selling online 20 years ago.
I lost the source code but people still wanted to buy it. So I sold it for few years (shareware). I had a serial key generator for windows but it was annoying to do this manually.. I wanted to extract the key generation algo so it can be generated automatically after payment.
I also tried many disassembly tools like ghidra, but without luck. I decided to stop selling / supporting the software.
Nowadays, I still get the occasional mail from people asking where they can buy it, or of there are some updates.
It's pretty clear that the program has utility, otherwise people wouldn't ask.
Giving it to computer cracking groups as a real world program that they can use as a teaching tool has some value too.
I mean, if you you're not willing to take the money for the program anymore, then you have little to lose with this.
(Unless there's some other reason not to do it, brand harm for example, or third-party code that's licensed and that you do not have permission to subgrant reverse engineering work)
For what it's worth, will probably run via WINE for long after Window's support fades... even though Windows itself is pretty legendary in terms of backwards compatibility.
It might not be that hard to make your own version of this, maybe average HSL values for each square or something. How are the available tile colors stored?
- 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 ....
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.
> Might be illegal to break someone else's proprietary software, no matter how abandoned it is.
Oh no!
Anyway
Snark aside, what you do locally on your own PC in your own home is kinda nobody else’s business, especially when you aren’t cracking it to share it with others. Pretty sure all the arguments were already hashed out in the ‘80s when VCR companies tried to block recording television to cassette tapes.
The horrors of non-free software...
When I become king of the United Continents, I will make a new rule: If you don't publish high-quality updates for your software for one year, it will become open source automatically.
Mm. I think "any" update would be sufficient for 95% of cases, doesn't have to be high-quality.
Even if it's just the copyright date changing at least once per year, that tells you one specific named entity is claiming to care about it: when nobody does even that much, everyone automatically has the right to do whatever they want with the software.
Which reminds me, I need to update the copyright date on my website…
> If you don't publish high-quality updates for your software for one year,
I don't think that Microsoft or Google will like this.
I don’t like it either but he’d be ‘king’ so it wouldn’t really matter if anyone liked it or not
It's not so easy https://en.wikipedia.org/wiki/Louis_XVI
Forced enshittification?
Fortunately it wasn't a SaaS that shut down.
I would first search keygen/crack archives to see if some famous scene group had already done the needful long ago, although for software as obscure as this, it's less likely. Then again, I've seen some very obscure software ("there's an app for that!?") when browsing those before.
You 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)
All the way I was thinking the same.
Why patch the binary to get the correct "system identity" value, to match the license/serial-key you've got? Instead patch the serial-check out of the software entirely.
For crackers, keygenning is more fun.
The problem with that software title is caused by a hostile licensing system it uses. It relies on an offline form of online activation where the activation key is tied to your installation ID, which in turn depends on OS/hardware identifier of your computer. This is an overkill IMO.
I cannot imagine people working with ceramic tiles cracking a static licensing system. Yes, they can overshare license keys but realistically this does not happen too often, and there are non-invasive ways to circumvent this.
I've worked on parts of a training platform for a specific professional group... There's literally been widespread hacks to bypass the need to watch mandated training material. You'd be surprised the efforts people will go through to get to/through something they need.
Kinda 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 worth it? These days I am just pulling React, TypeScript, and just do CSS. If I need a dependency I'll try to just code it from scratch with LLM. Is it realistic to expect, React, TypeScript to be maintenance free forever? Since those are basically just abstraction on top of HTML/JS/CSS which are rock solid.
Ideally the home-baked software that I build will be just using very simple technologies, and I can just vibe/LLM code all the dependencies, or worst case just vendor it, and update it once a year or longer.
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.
> probably
no. Pure win32, maybe, but as soon as vcredist or DirectX enters the scene, one is hopeless.
> is it realistic these days to just expect software to write once and run forever?
Yes, but you have to put a bit of effort to make it so. For example, if you write your software as a ROM for an early game console (SNES/GBA/etc.), you can probably expect it to run for a very long time, as there will likely be people who want to play Final Fantasy 6 and Pokémon Silver for as long as computers are around.
That's one extreme, but you don't have to go that far. I have some HTML/CSS/JS projects (meant to run locally) from the 2000s that still work totally fine today. Same for Python code from 2010, etc. I wouldn't be surprised if those still worked just fine 50 years from now.
All I do is write code that is meant to run locally first, with very minimal dependencies, only choosing to use conservative/proven technologies.
DOSBox! Super stable APIs that will never change. And it self-hosts compilers and editors (up to latest versions of Emacs and at least versions of vim from earlier this century) so anywhere your code can run you can also modify and recompile it.
(In practice I edit my code outside of DOSBox, and sometimes I use cross-compilers, but it is good to know that there is a fallback.)
> there will likely be people who want to play Final Fantasy 6 and Pokémon Silver for as long as computers are around
Is Final Fantasy 6 seeing a lot on new players today? Old games are played more by the people who enjoyed them when they were new. Even the landmark games are easily forgotten and younger players will never bother when they have so many modern choices.
The modern choices are accompanied by ads and gambling, to the point that it wouldn't be surprising if Final Fantasy 6 was seeing an uptick. Go enjoy your "modern" games all you like, but it doesn't always matter if a games community is growing, especially if it's not one requiring connectivity to blast ads and skins at people.
> Even the landmark games are easily forgotten and younger players will never bother when they have so many modern choices.
www.gog.com
Features regularly on HN
The Titan submersible implosion features a lot on HN, and almost nobody here built such a contraption, or took one to the bottom of the ocean, or imploded. Naming a gaming storefront which may sell an old game doesn't answer the question whether young people want to play it.
My reasonable baseline assumption is that almost no young player is going to jump to play a 30+ year old game. I'll be generous here and not name things like Frogger or worse, The Oregon Trail. But give a kid who has seen modern games a copy of Diablo, or SimCity 2000, or even newer things like or GoldenEye 007 or System Shock and watch the "excitement". And these are the heavy hitters.
A lot of these oldies didn't age well even for the people who loved them way back when. It's hard to get young players excited about them. Very few oldies could stand on their own today.
Some software does. If you've worked on SCADA gear it's expected to go into production and then run for 20-30 years without being patched once a month, or, actually, ever.
Someone once asked the author of an at the time widely-used security utility why it hadn't been updated since 1996, and whether it was abandonware. His response: "No, some people just get it right the first time". Just had a quick check and there's a single CVE for it from 25 years ago, possibly from a third-party mod rather than the original code.
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 expanded its utility.
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.
> But is it realistic these days to just expect software to write once and run forever?
From an engineering perspective, yes. From the current mindset in SW development (reinventing the wheel every couple of years) no. Almost all current SW is throw away software. For most of it you need a particular version of an OS, particular versions of libraries and a particular planet alignment, just to be able to run it.
I've used plenty of Common Lisp code from 30 even 40 years ago without issue.
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.
I was a beta tester for Freehand/MX, and used Freehand and Altsys Virtuoso for decades before that --- it still running on Windows is why I still use Windows, and I despair of what I will use for vector drawing when it stops running.
None of the Inkscape devs are invested in Freehand's keyboard shortcuts and working techniques, Graphite doesn't even work with a stylus, Cenon is clunky beyond words and hasn't been upgraded in decades last I checked, Krita is pixel-oriented, and none of the note-taking programs really work for technical drawing/vector editing....
You seem to be describing how the web dev worked after JQuery but before React. It wasn’t prettier than now.
I agree that the wider NPM ecosystem is a morass of slop and that is technical debt for anyone who wanders into that minefield. But the solution isn’t to assume that there are no bad / unmaintained GoLang libraries. It’s to realize that maintenance, quality, and sustainability need to be first class attributes of every library you choose to allow your project to depend on.
Your proposal will yield lots of LLM near-slop (basically code that works given the original prompt requirements, but will fail to continue working well once some requirement changes, some original assumption is violated, some browser changes are implemented.
Ultimately, the sustainable solution is to have a subset of NPM libraries be extremely high quality, vetted via robust tests and security audits, and are visibly different than the average slop on NPM. Basically a very visible delineation between untrustworthy code and very trustworthy code. Then you should be able to tell the LLM to use only dependencies from that vetted subset.
I'm not sure if it's abandon ware but I found a gist which attempted to get pictures from this Korean Kindergarten app for backup which we also use.
I tried it and it only half worked and you had to copy a cookie out of the browser which would expire after a couple of days.
I took it and extended it added a login with selenium or what it is called and now I can run it daily and get those pictures out and into my immich. Instance.
The script was already a couple of years old and outside of Korea nobody uses KidsNote, I made it used ware again: https://git.jeena.net/jeena/kidsnote-backup
I have a tangentially-related question. I've been using Novagraph Chartist since the Windows 3.1 days back when I was 17 (I'm now climbing 50!). It seems that the original company behind this has vanished, I've asked for support, but no joy there, I hope the author is still alive. I'm on Chartist 5.2. It needed online activation towards the end of its life.
Whilst in these modern days of hi-DPI screens and anti-aliased lines, I still love using Chartist - I know all of the keyboard shortcuts and I can use it to create a diagram faster than using anything else.
Does someone have a patch for it or something?
Thanks, Nick.
>I use a MacBook, and this application is Windows only, so executing it is out of the question.
This is where things went off the rails. Choosing hard paths should be done when you're exploring, and never when you're fixing a business issue. Why didn't they just try it out in a VM or even a mega cheap VPS? Why is doing it the easiest way imaginable completely out of the question?? I have no empathy for this kind of pain.
That'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!
I agree with you. If the source code is there, theoretically is not abandonware, but handed to the community.
To be fair, GitHub code rots much faster these days. I would assume anything with a specific job to do (not games) that is untouched for 8 months is circling the drain and expiring in another 8 months.
I generally go by the state of the issues and unmerged commits instead of just the last commit date. Some things are just functionally complete.
reminds me of my own software I created and was selling online 20 years ago. I lost the source code but people still wanted to buy it. So I sold it for few years (shareware). I had a serial key generator for windows but it was annoying to do this manually.. I wanted to extract the key generation algo so it can be generated automatically after payment. I also tried many disassembly tools like ghidra, but without luck. I decided to stop selling / supporting the software. Nowadays, I still get the occasional mail from people asking where they can buy it, or of there are some updates.
You could give someone permission to crack it.
It's pretty clear that the program has utility, otherwise people wouldn't ask.
Giving it to computer cracking groups as a real world program that they can use as a teaching tool has some value too.
I mean, if you you're not willing to take the money for the program anymore, then you have little to lose with this.
(Unless there's some other reason not to do it, brand harm for example, or third-party code that's licensed and that you do not have permission to subgrant reverse engineering work)
They told us that with AI you can vibe-code anything now...
So, no need to make old program to work. Just write new one.
/sarcasm
Or you could have AI figure out how to crack it.
For what it's worth, will probably run via WINE for long after Window's support fades... even though Windows itself is pretty legendary in terms of backwards compatibility.
It might not be that hard to make your own version of this, maybe average HSL values for each square or something. How are the available tile colors stored?
Might be illegal to break someone else's proprietary software, no matter how abandoned it is.
Try to ask them for source code, with the intention to open-source it. Then you (and maybe others!) can break it whole day long.
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 ....
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.
Or could just release the tool that issues new keys/serials/licenses.
> Might be illegal to break someone else's proprietary software, no matter how abandoned it is.
Oh no!
Anyway
Snark aside, what you do locally on your own PC in your own home is kinda nobody else’s business, especially when you aren’t cracking it to share it with others. Pretty sure all the arguments were already hashed out in the ‘80s when VCR companies tried to block recording television to cassette tapes.
Literally nobody cares.
Well, didn't think of that, but agree completely.
In order to sue the post author, the software copyright holder must claim some damages. I doubt they will find enough damages to pay legal fees.
> Pretty sure all the arguments were already hashed out in the ‘80s when VCR companies tried to block recording television to cassette tapes.
Why would VCR companies try to block this?
Not the VCR companies but the TV stations and Cable companies.