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

71–80 of 252 posts

Re: Software Rot

#71

Post by spauldo »

tanduv wrote: post #36
mmackh wrote: post #26

Earlier quoted context omitted.

Not if software is tied to infrastructure, buildings, etc.

but even buildings need maintained

Automation costs a lot. The projects I work on are almost always in the millions of dollars,band they're far from being considered "big" projects. The hardware manufacturers will sell you equipment that runs for thirty years. Companies are reluctant to replace working systems.

I replaced a PLC a couple years ago. The software to program it wouldn't run on my laptop because it used the win16 API. It used LL-984 ladder logic, and most people who were experts in that have retired. It's got new shiny IEC-compliant code now, and next they're looking at replacing the Windows 2000 machines they control it with. Once that's done, it'll run with little to no change until probably 2050.

Re: Software Rot

#72

Post by codeflo »

dgoldstein0 wrote: post #70
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 ma…

That's probably true, but you're describing incentives and social dynamics, not a technological problem. I notice that every other kind of infrastructure in my life that I depend upon is maintained by qualified teams, sometimes for decades, who aren't incentivized to rebuild the thing every six months.

Re: Software Rot

#73

Post by wolvesechoes »

Imustaskforhelp wrote: post #67
wolvesechoes wrote: post #23

Earlier quoted context omitted.

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

> If I remember correctly, ReactOS just uses wine under the hood

Nah. I think they share some effort and ReactOS team adds patches to WINE codebase, it is a separate thing.

Re: Software Rot

#74

Post by codeflo »

Ygg2 wrote: post #68
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 fi…

> People want your software to have more features, have fewer bugs, and not be exploited. So you and every one of your competitors are on an update treadmill. If you ARE stable, you'll probably fall off. If you are on the treadmill you are accumulating code, features, bug fixes, until you either get off or a faster competitor emerges.

Runners on treadmills don't actually move forward.

Re: Software Rot

#75

Post by xenodium »

While Emacs itself is not entirely immune to software rot (external dependencies and all), it’s truly amazing how little to no rot is experienced by elisp software (packages). If you find an Emacs package written 15 years ago, the chances of successfully running out of the box are incredibly high.

Re: Software Rot

#76

Post by b_e_n_t_o_n »

mmackh wrote: post #26
b_e_n_t_o_n wrote: post #15

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble?

Not if software is tied to infrastructure, buildings, etc.

Perhaps software should be designed in such a way that despite it working on infrastructure, it can be swapped and discarded.

Re: Software Rot

#77

Post by cjfd »

esseph wrote: post #56
cjfd wrote: post #49

Earlier quoted context omitted.

It is also quite possible for old containers to no longer build.

That's why your build pipeline alerts you when tests no longer work, and then you have a release of the previous build still available for download at any time. This is how containers are released!

Sure. It still is burdensome, though. Now there are lots of nightly build from old projects that break at random times and require developer attention.

Re: Software Rot

#78

Post by flomo »

saurik wrote: post #62
Ygg2 wrote: post #57

Earlier quoted context omitted.

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.

Not being a python dev, there must have been some huge superficial 'ick'. Back when, I was talking to a python guy and mentioned that Python 3 was coming out. He said something like "we're just going to ignore that until they sober-up and fix it." Which it seems like a lot of people actually did. (or they really sobered-up and rewrote in Go or something.)

Re: Software Rot

#79

Post by deafpolygon »

xenodium wrote: post #75

While Emacs itself is not entirely immune to software rot (external dependencies and all), it’s truly amazing how little to no rot is experienced by elisp software (packages). If you find an Emacs package written 15 years ago, the chances of successfully running out of the box are incredibly high.

That... has not been my experience.

Re: Software Rot

#80

Post by [deleted] »

eviks wrote: post #21
argomo wrote: post #9

Earlier quoted context omitted.

It has to be weighed against all the time spent learning, evaluating, and struggling with new tools. Personally, I've probably wasted a lot of time learning /new/ that I should have spent learning /well/.

Right, nothing is free, but switching costs is a different argument.

[deleted]
Post reply on HN