Hacker News Reader

Comment by ketralnis | Hacker News Reader

Sadly the days of "keep using the software" are mostly over. Between security updates and platforms frequently making backwards-incompatible changes you'll hit the wall eventually. The rest of the world has opted into the continous deathmarch treadmill and you're on it too whether you like it or not. We don't value stability, and we berate people for running software that's older than 4 months as positively geriatric and asking for any trouble they might have.

Want to keep running that old package? Cross an ubuntu versioning chasm and now you also need an ancient version of glibc which won't run on your Zany Zamboni fleet because your other requirement of libxml 5 won't work with it. Find a security problem? Well there's a newer version that's only been out for four minutes why aren't you on that already anyway? Oh we don't publish packages for your 4 week old npm yarn bower neonode, who still uses that?

View on HN

True, but I think the "continous deathmarch treadmill" is the real problem, well above any license changes.

It seems to me that a big reason for this is the rapid pace of exploit developments. Every system-level tool has to be able to quickly adapt to deal with those security issues, either in its own code or in its dependencies, and these of course bubble up the stack, such that you have to keep updating to protect your users. And these updates somewhat regularly force (or make it difficult to avoid) breaking compatibility. So if you're breaking compatibility in small ways, that makes is easier to say "well let me just make these bigger changes, while I'm already here". And of course there's also the competitive aspects of featuritis.

And this then causes the "Red Queen's race"[0], similarly to animal evolution, where if you don't adapt to the ecosystem, you go extinct.

[0] https://en.wikipedia.org/wiki/Red_Queen%27s_race

I think the bigger reason is simply that backwards compatibility is hard.

Some projects put in that work (e.g., PostgreSQL), but it comes at a significant tax on productivity that could otherwise be put into new features.

> I think the bigger reason is simply that backwards compatibility is hard.

Backward compatibility requires some care, but it's not exactly hard. Simply don't change interfaces or exposed behavior. You can always add new APIs, just don't break the current ones.

The only time it is hard is when there is a security vulnerability that is difficult to fix without breaking compatibility. But that's not very often.

I came of age in the culture of never, ever breaking compatibility. You'd get raked over the coals in design meetings for ever voicing such forbidden thoughts. It's a wonderful approach because everything just keeps working. As it should be. The software industry needs to grow up to what it used to be.

When you don't put in that work you're externalizing it onto others.

I think it should depend on the attack surface - is the software on a server that is exposed to the public? If it's relegated to private servers then it is easier to secure that.

those same businesses are spending $2M/yr on salesforce

Mind if I ask how is this related to the topic?

It's very funny that you used Bower as an facetious example. It's been deprecated for almost 6 years!

And it still works, right?

Good to know, core component of the company still uses it every build pulling all dependencies from internet.

Gonna be a hilarious ride when it breaks.

Artifactory means never having to say you're sorry.

everyone knows how to run binaries portably on Linux!

use the win32 binary under Wine

which version of wine?

Reply on news.ycombinator.com