4 ms·

Why would you want that?

by lrem 5y ago

blablabla123 5y ago
I think programs in /bin used to be usually statically linked. When updating the glibc for instance, this makes the change far more doable. In general dealing with static binaries is much less pain, especially when they haven't been compiled locally/by the distributor for this particular version of the distribution.
- drivebycomment 5y ago
  /sbin used to be statically linked on unix. The entire point of /sbin is the independence from almost everything else so that you can rely on them even when the system boots up in a weird state.
Wowfunhappy 5y ago
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.

Why would you want that?

by lrem 5y ago

Why would you want that?

I think programs in /bin used to be usually statically linked. When updating the glibc for instance, this makes the change far more doable. In general dealing with static binaries is much less pain, especially when they haven't been compiled locally/by the distributor for this particular version of the distribution.

drivebycomment 5y ago
/sbin used to be statically linked on unix. The entire point of /sbin is the independence from almost everything else so that you can rely on them even when the system boots up in a weird state.

Wowfunhappy 5y ago

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.