Seem like a lot of conclusions to take based on the usage of one JS linter alone.
82% of Open-Source Projects Suffer from Tool Rot
31–40 of 61 posts
Re: 82% of Open-Source Projects Suffer from Tool Rot
#32When did GCC stop being enough?
Make is pretty old at this point, so a long time ago ;)
Re: 82% of Open-Source Projects Suffer from Tool Rot
#33Sometimes I wonder if we're optimizing for the wrong things in the dependency management space: we used to have a distinction between "bleeding edge" and "stable" distribution schemes, with programmers (and users) picking the appropriate channel based on their stability and feature requires. That seems to have been mostly discarded: we now assume that a development dependency is broken and needs to be updated if it's…
I think it's also tied up with security - in the past, you could have one release cycle with a stable release coming out every n releases, but now, because of vulnerabilities, larger projects usually need to have two release cycles: one for the bleeding edge, and an LTS that gets security updates ported in. That's a lot of work to maintain, so a lot of projects just nix the LTS.
Definitely, and I do not blame projects whatsoever for nixing the LTS -- it's a lot of work!
Still, I wonder about the general propriety: not every bug fix is a security fix, and treating them as such produces noise and fatigue that reduces the overall effectiveness of vulnerability reporting (since engineers become desensitized to reports).
Much of Rust's ecosystem embodies this: there are crates (like serde and clap) that have extremely regular bugfix releases, but those fixes do not (to my knowledge) surface as security concerns; instead, they're usually small invariant checks or missing trait implementations.
Re: 82% of Open-Source Projects Suffer from Tool Rot
#34Most maintainer work on their project, they don't have the time to work permanent on tooling. Esecially when the tools work for them.
You don't need always the newest "sht".
Re: 82% of Open-Source Projects Suffer from Tool Rot
#35> 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 think part of the problem is that people aren't distinguishing trusted inputs from untrusted inputs. ReDoS is only a possible problem if untrusted inputs can cause it. Some inputs are trusted, and while it's not crazy to check them (people make mistakes), that's a different kind of concern. ReDoS is a potential security vulnerability, but only in certain special cases.
If arbitrary people can insert arbitrary code into what your service sends, and other people will then run it, then ReDoS isn't even the beginning of your security problems.
Re: 82% of Open-Source Projects Suffer from Tool Rot
#36We have run into this with the HL7 standards development organization. It is no longer possible to build new releases of artifacts from some of the older standards because the build process depends on obsolete custom tools which no longer run on modern operating system versions. In theory it might be possible to update the tools, or construct a virtualized build environment, but in practice they don't have enough resources to fight through all the issues.
Re: 82% of Open-Source Projects Suffer from Tool Rot
#37> 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?
Re: 82% of Open-Source Projects Suffer from Tool Rot
#38> 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…
This is just another example of someone with one experience in software development thinking that their experience can be applied universally. It really depends on the kind of software you're writing and the environment you're working in.
Re: 82% of Open-Source Projects Suffer from Tool Rot
#39software engineering is a constant fight against entropy. GitHub code search uncovers the scope of tool rot in open source projects.
Everyone wants to be Tony Stark, nobody wants to be the janitor. Thus things fall apart and get constantly rebuild, in a "good-enough-fashion", which is very reminiscent of biologic life. We are codes transport mechanism, without us, its not alive. And only good code gets copied, reused, to life on till heat death.
I love the Iron Man reference. Everyone is always chasing the shiny new thing. Since my company build devtools the shiny thing is the thing that usually gets rusty - which is kind of the whole point I guess.
Re: 82% of Open-Source Projects Suffer from Tool Rot
#40I have several intranet applications that I need to port to another web framework because of this specific issue. I guess it servers me right for not choosing the most popular framework for my applications.
don't worry during the migration another new amazing fx will hit and you'll already be using the old legacy thing.