3 ms·

"Free bug fixes without compiling". I think YMMV. It depends a lot on ABI/API stability and actual modularity of ... components. There's not always a guarantee

"Free bug fixes without compiling". I think YMMV. It depends a lot on ABI/API stability and actual modularity of ... components. There's not always a guarantee of that. Shared libraries add a lot of complexity to a system for the assumption that people can actually build modular code well in any language that can create a shared library. Sometimes you have to recompile because, while a #define might still exist, its value may have changed between versions, and chaos can ensue - including new, unexpected bugs - for free!

dgfitz 2y ago
My current day job has probably 60 apps the depend on one shared library. Static linking has its place pace, no doubt, but it should not be the norm.
- zamadatix 2y ago
  60 programs y'all maintain as part of an overall larger solution or 60 randomly selected apps maintained fully by 3rd parties that just happen to share the same major library version? The former often makes a lot of sense in terms of deployment or maintenance - it's all really 1 big system so why rebuild and deploy 60 parts to change 1 when it's all done by you anyways. I'm not sure that's really what every build environment should default to assuming is the use case though but going shared libraries makes a ton of sense for that regardless. 60 programs maintained and built by 3rd parties which just happen to share major version of a library (other than something like stdlib obviously) would seem nuts to manage in a single runtime environment (regardless of static or shared) though!
  - dgfitz 2y ago
    > 60 programs y'all maintain as part of an overall larger solution That, 100% is our scenario.
- ryandrake 2y ago
  To me, the worse situation is when you just want to install a little tool to do a 2 minute job, and apt decides it needs to pull in 60 dependencies. You spend more time fetching and installing all these crappy little libraries, then uninstalling them all later, than you do running the tool.

dgfitz 2y ago

My current day job has probably 60 apps the depend on one shared library. Static linking has its place pace, no doubt, but it should not be the norm.

zamadatix 2y ago
60 programs y'all maintain as part of an overall larger solution or 60 randomly selected apps maintained fully by 3rd parties that just happen to share the same major library version? The former often makes a lot of sense in terms of deployment or maintenance - it's all really 1 big system so why rebuild and deploy 60 parts to change 1 when it's all done by you anyways. I'm not sure that's really what every build environment should default to assuming is the use case though but going shared libraries makes a ton of sense for that regardless. 60 programs maintained and built by 3rd parties which just happen to share major version of a library (other than something like stdlib obviously) would seem nuts to manage in a single runtime environment (regardless of static or shared) though!
- dgfitz 2y ago
  > 60 programs y'all maintain as part of an overall larger solution That, 100% is our scenario.
ryandrake 2y ago
To me, the worse situation is when you just want to install a little tool to do a 2 minute job, and apt decides it needs to pull in 60 dependencies. You spend more time fetching and installing all these crappy little libraries, then uninstalling them all later, than you do running the tool.