5 ms·
Sadly the days of "keep using the software" are mostly over. Between security updates and platforms frequently making backwards-incompatible changes you'll hit
by ketralnis 3y ago
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?
- davidgerard 3y agoeveryone knows how to run binaries portably on Linux! use the win32 binary under Wine
- nickstinemates 3y agowhich version of wine?
- dustingetz 3y agothose same businesses are spending $2M/yr on salesforce
- rmbyrro 3y agoMind if I ask how is this related to the topic?
- Wowfunhappy 3y agoTrue, but I think the "continous deathmarch treadmill" is the real problem, well above any license changes.
- falcor84 3y agoIt 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 https://en.wikipedia.org/wiki/Red_Queen%27s_race
- jtc331 3y agoI 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.
- jjav 3y ago> 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.
- hinkley 3y agoWhen you don't put in that work you're externalizing it onto others.
- lpghatguy 3y agoIt's very funny that you used Bower as an facetious example. It's been deprecated for almost 6 years!