4 ms·

> "the dynamic linking hell that is present in most modern Unix-likes" WTF are you talking about... There has never been a "hell" of dynamic linking problems

by Galanwe 11y ago

> "the dynamic linking hell that is present in most modern Unix-likes" WTF are you talking about... There has never been a "hell" of dynamic linking problems on Unixes, this used to be a Windows problem. Even the "most modern unix-likes" doesn't make sense, since "most modern unix-likes" do not even use similar linking models.

fapjacks 11y ago
We have dependency management built into the package managers which hides that from us these days. Unix and Linux before package managers was kind of a pain. Now, I will totally give you that it was nothing like the "DLL hell" of Windows.
- reidrac 11y ago
  Then how can be that an incentive for Docker's adoption? Honest question; if, as you say, this is a solved problem thanks to package managers. I can't even remember the last time I had a real dependency problem deploying an application (using Debian; and CentOS before that), other than myself not doing things right (read: installing RPMs I found online and I shouldn't install).
  - fapjacks 11y ago
    Well I wasn't originally speaking wrt Docker, but Docker doesn't magically lose all the hard work done by package managers. You have total access to them in your containers.
- digi_owl 11y ago
  Frankly i think package managers are part of the problem, rather than the solution. From personal experience using a less elaborate variant of what nixOS/Guix offers (Gobolinux), ld and friends are quite adept at getting multiple lib versions sorted via sonames. But package managers do not use anything like sonames for resolving dependencies. This because foobar-1.0 and foobar-1.1 can't be installed at the same time. Instead you would have to do something like foobar-1.0 and foobar2-1.1, even though foobar2 is actually a minor upgrade to foobar. This because the logic of most package managers balk at having two packages with the same name, but different versions, installed at the same time.
dpc_pw 11y ago
What people mean is Python (and others scripting languages) dependency hell. Unix dynamic linking very rarely has any issues as static typing makes it relatively easy to reason about stable interfaces. The raise of containers, is consequence of raise of dynamic scripting languages, and rather un-unixy and "get it ready ASAP" culture, IMO. You can have 100 daemons written in C/C++ running on one system just fine, and that's how Unix systems used to work, but as soon as you start using software written in Python, you can't get two running system-wide, without recompiling every dependency into separate `virtualenv`. So it's easier to just throw them each in their own lightweight virtual machine, based on the recipe on how to rebuild the thing.
- vezzy-fnord 11y ago
  No, even Unix dynamic linking has problems because of symbol versioning, sonames and package managers adding a whole new policy layer to the shared library context that can lead to transactional and dependency conflicts. Though, yes, dynamic languages do add even more concerns.

by Galanwe 11y ago

fapjacks 11y ago

We have dependency management built into the package managers which hides that from us these days. Unix and Linux before package managers was kind of a pain. Now, I will totally give you that it was nothing like the "DLL hell" of Windows.

reidrac 11y ago
Then how can be that an incentive for Docker's adoption? Honest question; if, as you say, this is a solved problem thanks to package managers. I can't even remember the last time I had a real dependency problem deploying an application (using Debian; and CentOS before that), other than myself not doing things right (read: installing RPMs I found online and I shouldn't install).
- fapjacks 11y ago
  Well I wasn't originally speaking wrt Docker, but Docker doesn't magically lose all the hard work done by package managers. You have total access to them in your containers.
digi_owl 11y ago
Frankly i think package managers are part of the problem, rather than the solution. From personal experience using a less elaborate variant of what nixOS/Guix offers (Gobolinux), ld and friends are quite adept at getting multiple lib versions sorted via sonames. But package managers do not use anything like sonames for resolving dependencies. This because foobar-1.0 and foobar-1.1 can't be installed at the same time. Instead you would have to do something like foobar-1.0 and foobar2-1.1, even though foobar2 is actually a minor upgrade to foobar. This because the logic of most package managers balk at having two packages with the same name, but different versions, installed at the same time.

dpc_pw 11y ago

What people mean is Python (and others scripting languages) dependency hell. Unix dynamic linking very rarely has any issues as static typing makes it relatively easy to reason about stable interfaces. The raise of containers, is consequence of raise of dynamic scripting languages, and rather un-unixy and "get it ready ASAP" culture, IMO. You can have 100 daemons written in C/C++ running on one system just fine, and that's how Unix systems used to work, but as soon as you start using software written in Python, you can't get two running system-wide, without recompiling every dependency into separate `virtualenv`. So it's easier to just throw them each in their own lightweight virtual machine, based on the recipe on how to rebuild the thing.

vezzy-fnord 11y ago
No, even Unix dynamic linking has problems because of symbol versioning, sonames and package managers adding a whole new policy layer to the shared library context that can lead to transactional and dependency conflicts. Though, yes, dynamic languages do add even more concerns.