5 ms·

> thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they d

by zrm 2y ago

> thousands of people and multiple separate organizations poured blood sweat and tears into these various bundling technologies for no good reason. Why’d they do that? Because stability and rapid change are incompatible, and they wanted rapid change. Which turns into a maintenance nightmare because now every app is using a different, incompatible version of the same library and somebody has to backport bug fixes and security updates to each individual version used by each individual package. And since that's a ton of work nobody wants to do, it usually doesn't get done and things packaged that way end up full of old bugs and security vulnerabilities.

sunshowers 2y ago
I'm a big believer in not getting in the way when people want to build stuff. I get GitHub alerts for vulnerabilities in the dependencies of my Rust programs, and I release new versions whenever there's a relevant vulnerability. My programs work, pass all tests on supported platforms, and don't have any active vulns. Forcing dynamic binding on me is probably not a good idea, and certainly not work I want to do.
- AshamedCaptain 2y ago
  Do you keep multiple branches of your programs, including one where you do not add new features but only bugfixes and such security updates? (And I am skeptical of claims that leaf developers can keep up with the traffic of security updates)
  - sunshowers 2y ago
    I build my programs to be append-only, such that users can always update to new versions with confidence. For example, I'm the primary author and maintainer of cargo-nextest [1], which is a popular alternative test runner for Rust. Through its history it has had just one regression. If I did ever release a new major version of nextest, I would definitely keep the old branch going for a while, and make noises about it going out of support within the next X months. Security updates aren't that common, at least for Rust. I get maybe 5-6 alerts a year total, and maybe 1-2 that are actually relevant. [1] https://nexte.st/ https://nexte.st/
    - AshamedCaptain 2y ago
      > I build my programs to be append-only, such that users can always update to new versions with confidence. And in this wonderful world where developers are competent enough to manage this, and therefore there are no issues when libraries are updated (append-only, right?).... why do you have a problem with shared linking again? Or is this a case where you think yourself as an "above average" programmer?
      - sunshowers 2y ago
        I think the difference is that library interfaces tend to be vastly more complex than application interfaces, partly because processes form fairly natural failure domains (if my application does something wrong it exits with a non-zero code, but if my library does something wrong my entire program is suddenly corrupted.) There are also significant benefits to static linking (such as inlining and LTO) that are not relevant across process boundaries. But yes, in a sense I'm pushing the problem up the stack a bit. > is this a case where you think yourself as an "above average" programmer? I've been very lucky in life to learn from some of the best minds in the industry.
- kelnos 2y ago
  > I get GitHub alerts for vulnerabilities in the dependencies of my Rust programs, and I release new versions whenever there's a relevant vulnerability. That's great, but my confidence is very low that most maintainers are like you.
  - sunshowers 2y ago
    Sure! I'm an optimist at heart and think a lot of people can learn though :) And note that static linking doesn't prevent third-party distributors like Linux maintainers from patching software. It's just that a lot of the current tooling can't cope too well with tracking statically linked dependencies. But that's just a technical problem. GitHub's vulnerability tracking has been fantastic in this regard.

by zrm 2y ago

sunshowers 2y ago

I'm a big believer in not getting in the way when people want to build stuff. I get GitHub alerts for vulnerabilities in the dependencies of my Rust programs, and I release new versions whenever there's a relevant vulnerability. My programs work, pass all tests on supported platforms, and don't have any active vulns. Forcing dynamic binding on me is probably not a good idea, and certainly not work I want to do.

AshamedCaptain 2y ago
Do you keep multiple branches of your programs, including one where you do not add new features but only bugfixes and such security updates? (And I am skeptical of claims that leaf developers can keep up with the traffic of security updates)
- sunshowers 2y ago
  I build my programs to be append-only, such that users can always update to new versions with confidence. For example, I'm the primary author and maintainer of cargo-nextest [1], which is a popular alternative test runner for Rust. Through its history it has had just one regression. If I did ever release a new major version of nextest, I would definitely keep the old branch going for a while, and make noises about it going out of support within the next X months. Security updates aren't that common, at least for Rust. I get maybe 5-6 alerts a year total, and maybe 1-2 that are actually relevant. [1] https://nexte.st/ https://nexte.st/
  - AshamedCaptain 2y ago
    > I build my programs to be append-only, such that users can always update to new versions with confidence. And in this wonderful world where developers are competent enough to manage this, and therefore there are no issues when libraries are updated (append-only, right?).... why do you have a problem with shared linking again? Or is this a case where you think yourself as an "above average" programmer?
    - sunshowers 2y ago
      I think the difference is that library interfaces tend to be vastly more complex than application interfaces, partly because processes form fairly natural failure domains (if my application does something wrong it exits with a non-zero code, but if my library does something wrong my entire program is suddenly corrupted.) There are also significant benefits to static linking (such as inlining and LTO) that are not relevant across process boundaries. But yes, in a sense I'm pushing the problem up the stack a bit. > is this a case where you think yourself as an "above average" programmer? I've been very lucky in life to learn from some of the best minds in the industry.
kelnos 2y ago
> I get GitHub alerts for vulnerabilities in the dependencies of my Rust programs, and I release new versions whenever there's a relevant vulnerability. That's great, but my confidence is very low that most maintainers are like you.
- sunshowers 2y ago
  Sure! I'm an optimist at heart and think a lot of people can learn though :) And note that static linking doesn't prevent third-party distributors like Linux maintainers from patching software. It's just that a lot of the current tooling can't cope too well with tracking statically linked dependencies. But that's just a technical problem. GitHub's vulnerability tracking has been fantastic in this regard.