3 ms·

Nobody wants anything _ever_ to ”randomly update”. Why this is the default setting on so many development setups boggles my mind. I really havent figured out w

by fsloth 1y ago

Nobody wants anything _ever_ to ”randomly update”. Why this is the default setting on so many development setups boggles my mind. I really havent figured out why professional systems insist running on the bleeding edge - it’s your feet are bleeding here I believe. 10 year … 15 year old code is generally excellent if you know it through and thorough.

skydhash 1y ago
As my experience grows, I'm getting fonder of stances like Debian or Common Lisp, which favors stability. Once you've solved a problem, it's not fun having your foundation morphs under you for no other reasons than bundling features and security updates.
chrisweekly 1y ago
CVEs are a thing. If vulnerabilities are discovered in your dependency graph, choosing to ignore them can have severe consequences.
- fsloth 1y ago
  I don’t believe anything I wrote above promotes the idea of ignoring vulnerabilities as a standard procedure. CVE database is an excellent way to be informed about vulnerabilities and there are services to automatically map CVE reports to code bases.
  - chrisweekly 1y ago
    Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities. What's the alternative? Are you suggesting that backpatching transitive deps dating back over a decade-plus tineframe is a viable maintenance strategy?
    - fsloth 1y ago
      I'm suggesting the "default mode" would be that updating is explicit rather than automatic. The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.
      - chrisweekly 1y ago
        > "I'm suggesting the "default mode" would be that updating is explicit rather than automatic" This, I agree with. Though for modern codebases, leveraging tools like Dependabot is very helpful. Deliberate upgrades, with automation to make it practical.

by fsloth 1y ago

skydhash 1y ago

As my experience grows, I'm getting fonder of stances like Debian or Common Lisp, which favors stability. Once you've solved a problem, it's not fun having your foundation morphs under you for no other reasons than bundling features and security updates.

chrisweekly 1y ago

CVEs are a thing. If vulnerabilities are discovered in your dependency graph, choosing to ignore them can have severe consequences.

fsloth 1y ago
I don’t believe anything I wrote above promotes the idea of ignoring vulnerabilities as a standard procedure. CVE database is an excellent way to be informed about vulnerabilities and there are services to automatically map CVE reports to code bases.
- chrisweekly 1y ago
  Ok, but the context for the conversation is external dependencies, and you expressed a preference for code aged 10-15 years. I'm just saying that a codebase that's 10-15 years old, with any dependencies at all, is going to be rife with vulnerabilities. Thus the choice is either staying current or living with vulnerabilities. What's the alternative? Are you suggesting that backpatching transitive deps dating back over a decade-plus tineframe is a viable maintenance strategy?
  - fsloth 1y ago
    I'm suggesting the "default mode" would be that updating is explicit rather than automatic. The "10-15" year old comment can be taken in the context of language specifications for example. C++11 is a totally fine language standard, and since backward compatibility is the only reason for C++ to exist at this point there is no intrinsic benefit in using a later version.
    - chrisweekly 1y ago
      > "I'm suggesting the "default mode" would be that updating is explicit rather than automatic" This, I agree with. Though for modern codebases, leveraging tools like Dependabot is very helpful. Deliberate upgrades, with automation to make it practical.