3 ms·

Simplicity. If everything is statically linked, then updating package A can never break package B. As I see it, the entire world of Docker containers exists pr

Simplicity. If everything is statically linked, then updating package A can never break package B. As I see it, the entire world of Docker containers exists primarily to solve the problem that static linking already solved. Something like Nix would work as well, and I think I would love Nix if I knew how to use it. But I don't, and I don't really have the time to learn.

lrem 5y ago
I don't think that makes a lot of sense in a distro. If package A gets an update, it means a sufficiently bad bug was discovered in it. If it happens to be a library, you want to make sure you update every package B that uses it. Which, conveniently, the distro solves for you too.
- Wowfunhappy 5y ago
  This is true, but only if I'm actually getting everything from the distro repository and I'm able to keep all of it on the latest version. In practice, I sadly tend to run into situations where I need stuff from other places.
  - lrem 5y ago
    But then you don't want the software from the distro to be statically linked, but the software from other places. In which case it doesn't matter that much what does the distro do.
    - Wowfunhappy 5y ago
      The main use case for the distro itself being statically linked is being able to pin specific software at old versions. I wouldn't do this often, but it could be very helpful at times—sometimes even just temporarily for testing. But also, package managers in general make me kind of uncomfortable, because I feel like I never know the full state of my system. I've certainly run into library errors in the past with official packages (a long time ago), and while it's probably because I did something dumb, I also probably had a decent reason, and static linking would keep it all self-contained.
Brian_K_White 5y ago
AppImage, Flatpack, Snaps... all seem to be largely reinventing the primary qualities, good and bad, of static binaries in a new and much more complicated form. At least a container provides more function than mere bundling, but a lot of containers actually get used merely for bundling.

lrem 5y ago

I don't think that makes a lot of sense in a distro. If package A gets an update, it means a sufficiently bad bug was discovered in it. If it happens to be a library, you want to make sure you update every package B that uses it. Which, conveniently, the distro solves for you too.

Wowfunhappy 5y ago
This is true, but only if I'm actually getting everything from the distro repository and I'm able to keep all of it on the latest version. In practice, I sadly tend to run into situations where I need stuff from other places.
- lrem 5y ago
  But then you don't want the software from the distro to be statically linked, but the software from other places. In which case it doesn't matter that much what does the distro do.
  - Wowfunhappy 5y ago
    The main use case for the distro itself being statically linked is being able to pin specific software at old versions. I wouldn't do this often, but it could be very helpful at times—sometimes even just temporarily for testing. But also, package managers in general make me kind of uncomfortable, because I feel like I never know the full state of my system. I've certainly run into library errors in the past with official packages (a long time ago), and while it's probably because I did something dumb, I also probably had a decent reason, and static linking would keep it all self-contained.

Brian_K_White 5y ago

AppImage, Flatpack, Snaps... all seem to be largely reinventing the primary qualities, good and bad, of static binaries in a new and much more complicated form. At least a container provides more function than mere bundling, but a lot of containers actually get used merely for bundling.