To say that an outcome is "unidimensionally a good thing" does not imply that all interventions that have that outcome as part of their outcomes, are good interventions.
(to say nothing as to the question of whether the outcome in question actually is unidimensionally a good thing)
What shelf? A garage? Detached? A shed? How humid? You may want to resurface and oil that saw after a decade. The wood handle may have rotted, or the plastic one may be gummy. Taking care of tools is how they last.
That's cool, but if the 100 year old saw had been used regularly it would have required maintenance and sharpening to continue working well. Software also requires maintenance.
I can't think of any 100-year old software that is being used today (ha-ha).
I'm sure some airline reservation systems and banking systems written in COBOL in the 70s are still around, but they all have ongoing maintenance to keep them working correctly.
The commenter's complaint seems particularly worse with dynamic languages like JavaScript and Python than compiled things. Old projects written in node are often just as hard to get running or installed as something written in Python 2. The dependencies are out of date, you have to install an older version of Node.js, or the dependencies just don't exist anymore. And JS stuff usually generates a huge tree of dependencies even if they only directly rely on a handful of packages.
End of story, I think if these Python-2 tools/scripts were such a huge part of his project that they keep breaking builds, the company should be invest time in either rewriting them in their language of choice or maintaining those projects or a fork of those projects.
One of my old bosses was strict about this - no COMPANY projects should be relying on external package repositories, unapproved third-party dependencies, definitely not some github project maintained by only a few people. Yeah, I think if your company is relying on "requests" or some other massively popular project with tons of community maintenance, you don't want to fork that and it's important to use the standard versions. But if you're bringing in something that is used and maintained by only a few people - you either need to become part of the community that maintains it publicly or fork the project and maintain your own version.
This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
>This isn't NIH syndrome, it's basic protocol for keeping your builds reliable and dependency management simple.
Why should I, an end user, ever need to build WikidPad? I don't need to do so on Windows, why doesn't Linux support the same thing, shipping an executable?
When you go to the store, you're not presented with a set of tools for making a saw, you're given a complete, ready to go tool. Perhaps the very idea of users having to build things in Linux is the problem?
It is very similar to the problems with Windows, always pushing updates/upgrades that aren't necessary, and often break things. Windows machines are far less reliable on Wednesday than they are on Monday, because of Microsoft's idea of pushing patches on Tuesdays.
