Dealing with abandonware (2024)
blog.hris.to
Dealing with abandonware (2024)
1–10 of 55 posts
Re: Dealing with abandonware (2024)
#2So, no need to make old program to work. Just write new one.
/sarcasm
Re: Dealing with abandonware (2024)
#3Try to ask them for source code, with the intention to open-source it. Then you (and maybe others!) can break it whole day long.
Re: Dealing with abandonware (2024)
#4I 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.
Re: Dealing with abandonware (2024)
#5They 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
Re: Dealing with abandonware (2024)
#6Might 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.
- 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.
Re: Dealing with abandonware (2024)
#7I 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.
Re: Dealing with abandonware (2024)
#8Might 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.
Re: Dealing with abandonware (2024)
#9I 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.
Re: Dealing with abandonware (2024)
#10Kinda 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…
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.