3 ms·

> you might as well have made a static binary; it certainly would be easier to work with Not all programming languages can produce static binaries. That's the

> you might as well have made a static binary; it certainly would be easier to work with Not all programming languages can produce static binaries. That's the point of an image format to begin with. Reducing redundant code is a nice idea, but there aren't any systems^1 that solve for dependency hell and disk efficiency, and I'd rather trade a few hundred MBs of disk than fight with dependency hell. ^1: This isn't entirely true; Nix (and friends) do solve for this, but it's a relatively niche system and it's got its own usability issues that are (in my opinion) well worth sacrificing some disk to avoid. If these systems cross that threshold, then I'm happy to jump on that bandwagon.

michaelmrose 8y ago
As a user of linux on the desktop since 2003 I haven't seen any "dependency hell" save for packages not designed for the current distro/version or software not properly packaged. Usually proprietary crap NOT in your distros repos.
tomc1985 8y ago
APT (on linux) and MSI (on Windows) platforms both attempt to solve for those factors. Both are also bedrocks for the the operating systems they are designed for. Everyone else on this thread seems to be skipping right over both these names. Why?
- weberc2 8y ago
  Can't speak to MSI, but apt doesn't do a very good job. For me, this manifests in an error like "one of your packages is broken, run again with the -f flag to fix it" which has never ever ever worked for me ever. I've had some luck with aptitude in the past, but it often fails to resolve because you're only allowed one version of a package on your system at a time. Static linkage on the other hand is pretty close to foolproof.
  - tomc1985 8y ago
    dpkg, which is what underlies APT, is really picky. Definitely a downside for APT, but its a solved problem. Wasn't aware of the one-version issue with APT, though MSI definitely allows multiple versions (and attempts to manage the resulting dll hell)
    - weberc2 8y ago
      Ok, perhaps I should have said I’m not aware of any Linux package managers that support installing multiple versions of the same package except for Nix which manages it by munging the dynamic library lookup paths at runtime so the binary loads the right versions of its dependencies. Without this, I don’t think it’s possible to (correctly) support multiple versions, and even then the package maintained must take care that multiple versions of the same package don’t wind up in the closure (or the loader will load the first it encounters in the search path).

michaelmrose 8y ago

As a user of linux on the desktop since 2003 I haven't seen any "dependency hell" save for packages not designed for the current distro/version or software not properly packaged. Usually proprietary crap NOT in your distros repos.

tomc1985 8y ago

APT (on linux) and MSI (on Windows) platforms both attempt to solve for those factors. Both are also bedrocks for the the operating systems they are designed for. Everyone else on this thread seems to be skipping right over both these names. Why?

weberc2 8y ago
Can't speak to MSI, but apt doesn't do a very good job. For me, this manifests in an error like "one of your packages is broken, run again with the -f flag to fix it" which has never ever ever worked for me ever. I've had some luck with aptitude in the past, but it often fails to resolve because you're only allowed one version of a package on your system at a time. Static linkage on the other hand is pretty close to foolproof.
- tomc1985 8y ago
  dpkg, which is what underlies APT, is really picky. Definitely a downside for APT, but its a solved problem. Wasn't aware of the one-version issue with APT, though MSI definitely allows multiple versions (and attempts to manage the resulting dll hell)
  - weberc2 8y ago
    Ok, perhaps I should have said I’m not aware of any Linux package managers that support installing multiple versions of the same package except for Nix which manages it by munging the dynamic library lookup paths at runtime so the binary loads the right versions of its dependencies. Without this, I don’t think it’s possible to (correctly) support multiple versions, and even then the package maintained must take care that multiple versions of the same package don’t wind up in the closure (or the loader will load the first it encounters in the search path).