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.
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 don't think that Microsoft or Google will like this.
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.
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.
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 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.
no. Pure win32, maybe, but as soon as vcredist or DirectX enters the scene, one is hopeless.
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.
(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.)
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.
www.gog.com
Features regularly on HN
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.
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.
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.
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.
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 never escape security patches, but your theory of limiting to a free stable dependencies usually works really well for me.
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....
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 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
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.
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.
Oh shit, no new commit in 8 months! Abandonware!
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)
So, no need to make old program to work. Just write new one.
/sarcasm
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.
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.
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.
Why would VCR companies try to block this?