Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

82% of Open-Source Projects Suffer from Tool Rot

blog.trunk.io

Post reply on HN
Print view View original

41–50 of 61 posts

Re: 82% of Open-Source Projects Suffer from Tool Rot

#41

Post by dwheeler »

This seems to equate linters with other kinds of tools, and I think that's mistaken.

Linters attempt to look for "less than best practices". When you update a linter, you often also need to update code for the new style rules (unless you just don't care about the results). Those reports can be helpful, because those style rules can also warn about real problems like security vulnerabilities. But most are minor issues, so it may make sense to delay them.

I would generally prioritize outputs of tools that are designed to find serious problems (like security vulnerabilities), and then update things like linters when I can (but consider those lower priority). We should be unsurprised to find developers prioritizing some kinds of reports over others.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#42

Post by dpkirchner »

Macha wrote: post #14

The practical consequences of running an outdated eslint version are, for most projects, zero. The cost of upgrading is non zero. So upgrading only happens when there's a compelling reason to update like: - A real security issue - things like the reDoS example cited are part of the crying wolf that causes people to treat security scanners less seriously - A new feature (lint rule in eslint's case, or maybe new JS syn…

- There's a bug in one of the linters that is giving false positives (passing good code or missing bad code). This may not be a security issue, it may just result in poor code quality.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#43

Post by detaro »

dpkirchner wrote: post #37
krona wrote: post #20

> It’s important to call out that up until v4 ESLint was vulnerable to a Regular Expression Denial of Service attack (ReDoS). If one points out ReDos 'vulnerabilities' in tooling as a reason to upgrade it, you've instantly lost the argument. By the same logic we should ban TypeScript because its type system is turing complete. This reasoning isn't even wrong.

I don't understand the comparison between ReDoS vulnerabilities and TypeScript's type system. Could you elaborate?

ReDoS vulnerabilities in tooling - that's the key point. The "risk" is that if you do something weird in your code, then your linter might take a long time or crash (i.e. by running out memory). The same way that doing crazy things with types can make your compiler take a long time or crash (- type system).

Re: 82% of Open-Source Projects Suffer from Tool Rot

#44

Post by dpkirchner »

0cf8612b2e1e wrote: post #28
michaelmior wrote: post #10

Earlier quoted context omitted.

Depends what you mean by works . Of course installing the same version of the tool will in most cases keep doing the same thing it's always done. But it's possible the tool always had bugs that were never noticed, has significant improvements that could benefit the project, etc.

I would settle for knowing I could still build it. It is amazing how fragile build chains are and the amount of maintenance they require. The build tools themselves, let alone pulling in dependencies.

This is the main reason I'm so happy when I see builds run in docker containers. I don't have to worry as much about tracking down the exact dependencies that we're used to build a specific release.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#45

Post by dpkirchner »

detaro wrote: post #43
dpkirchner wrote: post #37

Earlier quoted context omitted.

I don't understand the comparison between ReDoS vulnerabilities and TypeScript's type system. Could you elaborate?

ReDoS vulnerabilities in tooling - that's the key point. The "risk" is that if you do something weird in your code, then your linter might take a long time or crash (i.e. by running out memory). The same way that doing crazy things with types can make your compiler take a long time or crash (- type system).

I didn't consider TypeScript tooling. I guess that makes sense since it's usually converted to JavaScript instead of being run directly where errors would affect end users.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#46

Post by rhdunn »

There are roughly 3 classes of dependencies:

1. key system dependencies -- this includes things like Android APIs, IDE APIs, etc. ~ to work on newer versions of those platforms, you need to upgrade and make changes to the code

2. other runtime dependencies -- these are dependencies used to make the system run, but that don't need to be updated in sync with the target platform ~ this can be things like the version of Spring, a HTTP library, etc.

3. development dependencies -- these are dependencies used to build the project

The system dependencies result in a treadmill, where if you don't keep up with the changes then your application, plugin, etc. will no longer work on the latest version. Just keeping up with these can be a lot of work, especially if you need/want to support multiple versions.

The other dependencies can cause headaches when upgrading major (or even minor) versions. For example, making sure that all the libraries you use are compatible when upgrading another library or language (Scala, Python, Java, PHP, etc.). This can be a lot of work to make sure that nothing is broken.

Development dependencies are typically low on the priority of things to upgrade. If the version of ESLint you are using works and there are no key benefits of performing an upgrade, then it is less likely to be upgraded.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#48

Post by hakre »

michaelmior wrote: post #10
jhoelzel wrote: post #3

Buuuut is it tool rot though if it still works?

Depends what you mean by works . Of course installing the same version of the tool will in most cases keep doing the same thing it's always done. But it's possible the tool always had bugs that were never noticed, has significant improvements that could benefit the project, etc.

To prolongue instead of "etc." what is often of more interest for those who build:

- configuration changes in the new versions

- undocumented changes in the new versions

- subtle changes in the build result that lead to flaws in the artefacts

- some of them leading to security flaws (those in the real camp)

- some of them leading to data-loss when running on production systems.

But sure, if you have kept the linter up-to-date ... .

Re: 82% of Open-Source Projects Suffer from Tool Rot

#49

Post by marginalia_nu »

dahfizz wrote: post #15

> Software projects have very short shelf lives. The moment a commit lands on main the software is spoiling; new versions of runtimes and compilers are shipped, dependencies cut new releases with bug fixes and exciting new features, and connected APIs are deprecated. Does this ring true for anyone? This sounds like hell. I am so glad to be in a field that minimizes third party dependencies. The C code I write today w…

The C++ code I wrote in 2008 doesn't compile today, despite depending only on libSDL. Lots of small things that have broken, mostly GCC behaving differently.

Still miles better than the JS and cloud spaces where code has such a short half-life you need to handle it with tongs and keep it in a lead box when you aren't using it, but still. All code rots.

Re: 82% of Open-Source Projects Suffer from Tool Rot

#50

Post by attractivechaos »

The open-source community did this to themselves. When the most popular frameworks and foundation tools (e.g. Python) disregard backward compatibility again and again, we have taken broken compatibility for granted and formed habit of pinning specific versions. It was not like this a decade ago. At that time, we more often assumed a minor version bump in dependencies would naturally keep everything running without hassles.
Post reply on HN