by SoftTalker
0 subcomment
- This is how software used to be before the internet.
You'd write (or buy) software for a purpose, and once it was debugged and installed, it was done. You just ran it after that. It was not exposed to external attackers, it didn't need to ever be updated unless new features were needed. In some cases (i.e. games on ROM cartridges) it couldn't be updated.
This is part of why Y2K was such an issue. So much old software was never intended to be updated. Preservation of original sources and build tools wasn't well managed. In many cases, software that had been in use for years or decades just had to be completely replaced because there was no practical way to update it.
by yomismoaqui
3 subcomments
- Lately I'm thinking about which could be the tech stack that enables a project that will keep running for 10-20 years with the least amount of maintenance.
Right now it's this:
- HTML/CSS/vanilla JS for the UI. If it renders on a browser now I expect it to render almost the same in 20 years.
- SQLite: It's a library that sure will be alive, maintained and API compatible in the future.
- Go: The Go 1 compatibility promise applies here. Also, trying to reduce external dependencies as much as possible (SQLite lib should use standard DB api)
Sure you can use C or Java, but Go strikes the right balance for me (also personal preference for its philosophy and ecosystem)
It's a nice thought experiment in a time when you leave a NextJS project for a year and it ages like milk.
- Really nicely written and quite thought-provoking. I think about when I die, will anyone be able to use or maintain any of the software I've written? Updates and patches are something so entwined with software that I doubt much of my code would be worth using if it suddenly froze.
It puts a beautiful spotlight on OSS communities and what they do to keep software alive through refactoring, iteration, patching. Also, on well-written documentation— perhaps that's even more important than the code for longterm maintenence and value. A good thesis that encourages someone to write it again, and better?
- “Cold-blooded software” concisely expresses something I’ve thought about for years. Modern software based on HTML/CSS and frameworks works great so long as maintenance is ongoing. But for software I write for myself, I much prefer cold-blooded software. I want to write it today and have it still work in five years, even if I haven’t done any maintenance. Professionally I work in an area with similar needs. Gonna be adding this term to my vocabulary.
- Tool vendor choice is one of the most important factors in whether or not things will work next year or decade. Using vendors who take stewardship over their ecosystem is at the heart of it all. The solutions to project rot are actually quite obvious if we will allow for them to be. Being required to vendor-in a vast majority of your dependencies is the biggest hallmark of a neglected ecosystem.
- Made this mistake years ago: figured I’d just throw it in a Docker with Python 2.7, problem solved. 8 years later nothing builds anymore. Base images gone, dependencies don’t resolve. Turns out containers don’t actually freeze time, they just delay the pain.
- Previously (2023; 222 comments): https://news.ycombinator.com/item?id=38793206
- https://news.ycombinator.com/item?id=38793206
by underdeserver
1 subcomments
- Should be (2023).
Hacker News