Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Rot

permacomputing.net

Post reply on HN
Print view View original

131–140 of 252 posts

Re: Software Rot

#131

Post by skydhash »

mezyt wrote: post #99
sebtron wrote: post #33

Earlier quoted context omitted.

Python is a very bad example because of the incompatibility between Python 2 and Python 3. All my pre-2012 Python code is now legacy because of this, and since most of it is not worth updating I will only be able to run it as long as there are Python 2 interpreters around. I like Python as a language, but I would not use it for something that I want to be around 20+ years from now, unless I am ok doing the necessary…

There's a script to update from python2 to python3, it's now the most used language in the world, and they learned their lessons about the python2 to python3 migration. A python3 script is literally the most likely candidate to be still working/maintenable by someone else in 20 years.

They are actively removing modules from the base install.

Re: Software Rot

#132

Post by donatj »

forgotmypw17 wrote: post #2

This and Lindy Effect factors a lot into my choices for what to use for my projects. My choice for a project I want to be as maintenance-free as possible are special subsets of ASCII/txt, SQLite, Perl, Bash, PHP, HTML, JS, CSS. The subsets I choose are the parts of these languages which have persisted the longest. Using the Lindy Effect for guidance, I've built a stack/framework that works across 20 years of differen…

I love PHP, however since around 7.4 they have become pretty happy to make breaking changes to the language, including recently in ways where you cannot satisfy older and newer versions of the runtime simultaneously.

I end up spending often a couple weeks of my life on and off fixing things after every major release.

Re: Software Rot

#133

Post by skydhash »

roda73 wrote: post #123

This is one of the reasons I absolutely hate Linux based development and operating systems built with it. We all know it now as dependency hell, but what it is in fact is just a lazy shortcut for the current development that will bite you down the path. The corporate software is not a problem, because the corporate users don't care as long as it works now, in the future they will still rely on paid solutions that wil…

It’s all volunteer work, not some corporation with trillions laying around. If you want something easy, use Debian (or ubuntu). They pretty much have everything under the sun.

What you want to have (download software from the net and run it) is what most distro have been trying to avoid. Instead, they vet your code, build it, and add it to a reputable repo. Because no one wants to download postgres from some random sites.

Re: Software Rot

#134

Post by munchler »

perrygeo wrote: post #124

I don't like the term "rot" - your software isn't rotting, it's exactly the same as when you last edited it. The rest of the software ecosystem didn't "rot" either, it evolved. And your old code didn't. "Extinction" seems a much better fit.

If we're just going by word meanings, "obsolescence" seems even more apt, but "rot" has an ironic charm that makes it memorable.

Re: Software Rot

#135

Post by saurik »

esseph wrote: post #61
saurik wrote: post #59

Earlier quoted context omitted.

But now I have frozen an old language runtime and a bunch of old libraries into my environment, all of which are not just security hazards but interoperability landmines (a common one being lack of support for a new TLS standard).

Write a wrapper, don't expose the container. These are different problems from the distribution/bundling piece, they won't be solved the same way.

I don't see how that solves either problem. If the thing in the container makes a web request out, that code both might become obsolete and offers an attack surface to get back in, and wrapping the outside of it doesn't change anything.

Re: Software Rot

#136

Post by asa400 »

SQLite has an explicitly stated policy on this: "The intent of the developers is to support SQLite through the year 2050."

https://www.sqlite.org/lts.html

People talk about SQLite's reliability but they should also mention its stability and longevity. It's first-class in both. This is what serious engineering looks like.

Re: Software Rot

#137

Post by BirAdam »

The most reliable targets I’ve seen recently are Win32 and CGI. They just work. Linux, Windows, macOS. Decade after decade.

Re: Software Rot

#138

Post by biscuits1 »

". . . whose specifications are static and solid." Well, thats the problem with software. There isn't agreement of such specifications. We aren't working with wood, nails nor forming a sill footing on bedrock.

Re: Software Rot

#139

Post by veggieroll »

icameron wrote: post #18

Nobody has a better ecosystem of “industrial marine grade code rot resistance” than Microsoft. That I can run the same .NET web app code compiled 20 years ago on a new Server 2025 is an easy experience unequaled by others. Or the same 30 year old VBA macros still doing their thing in Excel 365. There’s a company that knows how to do backwards compatibility.

I don't have experience with .NET. So that's nice to hear you've got a reliable setup. But, this has generally not been my experience with Microsoft.

There's tons of old programs from the Windows 95-XP era that I haven't been able to get running. Just last week, I was trying to install and run point and click games from 2002 and the general advise online is to just install XP. There was a way (with some effort) to get them working on Windows 7. But, there's no way to get them to work that I've seen on 10/11.

Re: Software Rot

#140

Post by count-delight »

ajuc wrote: post #35
nektro wrote: post #31

lovely article aside from this bit: > while those written for e.g. Linux will likely cease working in a decade or two there's nothing to support this claim in practice. linux is incredibly stable

I also noticed this part of the article but for the oposite reason (I think 10-20 years is overly optimistic). I've written a small 2d game for Linux back in 00s. Using C++, SDL and a few other libraries (for example now-abandoned libparagui for GUI). Any time I tried to run it afterwards - I had to recompile it, and a few times I had to basically port it (because libparagui got abandoned and some stuff in libc chang…

Something I've been pondering recently: It is sometimes said that Apple is notorious on deprecating APIs and breaking backwards-compatibility at a rapid pace, but is it not fundamentally the same that is shared with Linux? Old developers lamenting that they have developed something useful in 2015-2015 that doesn't work in any more in 2025. And if Linux distributions do it and it can be thought to be a form of opinionated design, can Apple be blamed for it? Unix/FreeBSD legacy and all.

Of course with Apple ecosystem you need relatively recent hardware and have to pay the annual developer program fee, but the expectation is still the same: if you release something, you should keep it up-to-date and not just "fire and forget" like in Windows and expect it to work. Maybe Windows is the anomaly here.

Post reply on HN