3 ms·

Grrr - I strongly, viscerally disagree! All of these new dependency bundling technologies were explicitly created to get out from under the abysmal state of pa

Grrr - I strongly, viscerally disagree! All of these new dependency bundling technologies were explicitly created to get out from under the abysmal state of packaging - from Docker (in some ways) and on to snap, flat pack, appimage, etc. This state of affairs was explained in no uncertain terms and widely repeated in the various manifestos associated with those projects. The same verbiage is probably still there if you go look. It seems crazy to act as if this recent memory is obscured by the mists of time, leaving us free to speculate on the direction of causality. We all lived this, and that’s not how it happened! Besides, in your telling, 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? I can’t help but suspect your answer is something like “it all worked fine, people just got lazy. Just simply work with the distro maintainer to get your package accepted and then … etc etc etc”. What do people have to do to communicate with the Linux people that this method of distribution is sucky and slow and excruciating? They’ve built gigantic standalone ecosystems to avoid doing it this way, yet the Linux people are still smugly telling themselves that people are just too stupid and lazy to do things The Right Way.

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.
AshamedCaptain 2y ago
We have such a myriad "dependency bundling technologies", dating back over more than a decade by now, and the situation has only been made worse. It's way too comfortable for _developers_ to bundle dependencies. That already explains why there is pressure to do so. You yourself look at this with developer glasses. I think users couldn't care less or may even actively avoid dependency bundling. Cause my impression, as a user, is that not only they almost never work right, but they actually make compatibility _harder_, not easier. And they decrease desktop environment integration, they increase overhead in every metric, they make patching things harder, etc. etc. Can you find other reasons why all these technologies you mention are not flying at all for desktop Linux users? And speaking as a developer, the software I develop is usually packaged by distros (and not myself), so I'm very well aware of the "sweating" involved. And despite that, I will say: it is not as bad as the alternatives presented.

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.

AshamedCaptain 2y ago

We have such a myriad "dependency bundling technologies", dating back over more than a decade by now, and the situation has only been made worse. It's way too comfortable for _developers_ to bundle dependencies. That already explains why there is pressure to do so. You yourself look at this with developer glasses. I think users couldn't care less or may even actively avoid dependency bundling. Cause my impression, as a user, is that not only they almost never work right, but they actually make compatibility _harder_, not easier. And they decrease desktop environment integration, they increase overhead in every metric, they make patching things harder, etc. etc. Can you find other reasons why all these technologies you mention are not flying at all for desktop Linux users? And speaking as a developer, the software I develop is usually packaged by distros (and not myself), so I'm very well aware of the "sweating" involved. And despite that, I will say: it is not as bad as the alternatives presented.