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

61–70 of 252 posts

Re: Software Rot

#61

Post by esseph »

saurik wrote: post #59
esseph wrote: post #46

Earlier quoted context omitted.

This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.

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.

Re: Software Rot

#62

Post by saurik »

Ygg2 wrote: post #57
foxrider wrote: post #37

Python 2 situation opened my eyes to this. To this day I see a lot of py2 stuff floating around, especially around work environments. So much so, in fact, that I had to make scripts that automatically pull the sources of 2.7.18 and build them in the minimal configuration to run stuff.

Python 2 is a warning about doing backwards compatibility changes too late. As soon as you have a few massive libraries, your backward compatibility risks grow exponentially. C# did just as big of a change by going from type-erased to reified generics. It broke the ecosystem in two (pre- and post- reified generics). No one talks about it, because the ecosystem was so, so tiny, no one encountered it.

It certainly didn't help that they were annoying about it; like, they actively dropped some of the forward compatibility they had added (a key one being if you had already carefully used u and b prefixes on strings) in Python 3.0, and only added it back years later after they struggled to get adoption. If they had started their war with Python 3.5 instead of 3.0 it would be a lot less infuriating.

Re: Software Rot

#63

Post by gbin »

zeta0134 wrote: post #50
esseph wrote: post #46

Earlier quoted context omitted.

This is one of the problems that containers help solve - no OS, just the dependencies required to run your code.

Python even has venv and other tooling for this sort of thing. Though, admittedly I seem to have dodged most of this by not seriously writing lots of python until after Python3 had already happened. With any luck the maintainers of the language have factored that negative backlash into future language plans, but we'll see. Mostly I recoiled in horror at bash specifically, which in addition to bash version, also ends…

How many times the virtualenv/pipenv/pyenv/... changed though? The package management also between wheels and setup and all the breakages.

Even for somebody that did not aim to have python programs for 20y, python is definitely not a good example of a "pdf for programs"

Re: Software Rot

#64

Post by saurik »

whizzter wrote: post #48
joegibbs wrote: post #45

I think don’t worry too much about trying to avoid it. Think 5-10 years ahead max, rather than 20. In 20-30 years there’s a good chance that what you’ve written will be obsolete regardless - even if programs from 1995 ran perfectly on modern systems they’d have very few users because of changing tastes. A word processor wouldn’t have networked collaborative editing (fine for GRRM though), an image editor wouldn’t hav…

2005 is already 25 years ago, and what the author is hinting at is the difference in difficulty between keeping 1980s software running vs keeping 2005 software running is momentous. 1980s NES software is "easy" as in emulating a CPU and the associated hardware (naturally there are corner cases in emulation timing that makes it a lot harder, but it's still a limited system). I used to make demos as mentioned in the ar…

> 2005 is already 25 years ago

o_O

Re: Software Rot

#65

Post by oguz-ismail »

eviks wrote: post #58
oguz-ismail wrote: post #53

Earlier quoted context omitted.

> poorly designed tools like bash and perl Skill issue, plus what's the alternative? Python was close until the 3.x fiasco

Indeed, double skill issue: one with the designers and the other one with the users having poor tool evaluation skills

> poor tool evaluation skills

Both tools in question are installed everywhere and get the job done. There isn't much to evaluate, and nothing to compare against

Re: Software Rot

#66

Post by rgmerk »

You can't build permanent software in a world where a) everything is connected to everything else, and b) hackers will exploit anything and everything they can get their hands on.

Re: Software Rot

#67

Post by Imustaskforhelp »

wolvesechoes wrote: post #23
userbinator wrote: post #14

those written for e.g. Linux will likely cease working in a decade or two Have we already passed the era of DON'T BREAK USERSPACE when Linus would famously loudly berate anyone who did? I suspect Win32 is still a good target for stability; I have various tiny utilities written decades ago that still work on Win11. With the continued degradation of Microsoft, at least there is WINE.

I would love ReactOS to succeed.

If I remember correctly, ReactOS just uses wine under the hood. Which can be used in linux and even mac or bsd too.

Basically (compile to windows?) seems like a good enough tradeoff to run anywhere, right?

But I prefer appimage or flatpak because of the overhead that wine might introduce I suppose

Re: Software Rot

#68

Post by Ygg2 »

codeflo wrote: post #44

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

> When and why has "stable" become synonymous with "unmaintained"?

Because the software ecosystem is not static.

People want your software to have more features, be more secure, and be more performant. So you and every one of your competitors are on an update treadmill. If you ARE standing (aka being stable) on the treadmill, you'll fall off.

If you are on the treadmill you are accumulating code, features, and bug fixes, until you either get too big to maintain or a faster competitor emerges, and people flock to it.

Solving this is just as easy as proving all your code is exactly as people wanted AND making sure people don't want anything more ever.

Re: Software Rot

#69

Post by noduerme »

I wish I could write all the business logic I write on an NES and never have to worry about requirements going bad. I guess the thing is, if you're writing anything on top of a network layer of any kind, eventually it's going to require patches unless you literally own all the wires and all the nodes in the network, like a secure power plant or some money clearing system in a bank that's been running the same COBOL since the 1960s. And since you're probably not writing code that directly interfaces with the network layer, you're going to be reliant on all the libraries that do, which in turn will be subject to change at the whims of breaking changes in language specs and stuff like that, which in turn are subject to security patches, etc.

In other words, if you need your software to live in the dirty world we live in, and not just in a pristine bubble, things are gonna rot.

Picking tools and libraries and languages that will rot less quickly however seems like a good idea. Which to me means not chaining myself to anything that hasn't been around for a decade at least.

I got royally screwed because 50-60% of my lifetime code output before 2018, and pretty much all the large libraries I had written, were in AS3. In a way, having so much code I would have maintained become forced abandonware was sort of liberating. But now, no more closed source and no more reliance on any libs I don't roll or branch and heavily modify myself.

Re: Software Rot

#70

Post by dgoldstein0 »

codeflo wrote: post #44

We as an industry need to seriously tackle the social and market dynamics that lead to this situation. When and why has "stable" become synonymous with "unmaintained"? Why is it that practically every attempt to build a stable abstraction layer has turned out to be significantly less stable than the layer it abstracts over?

So one effect I've seen over the last decade of working: if it never needs to change, and no one is adding features, then no one works on it. If no one works on it, and people quit / change teams / etc, eventually the team tasked with maintaining it doesn't know how it works. At which point they may not be suited to maintaining it anymore.

This effect gets accelerated when teams or individuals make their code more magical or even just more different than other code at the company, which makes it harder for new maintainers to step in. Add to this that not all code has all the test coverage and monitoring it should... It shouldn't be too surprising there's always some incentives to kill, change, or otherwise stop supporting what we shipped 5 years ago.

Post reply on HN