4 ms·

It's been said several times before that a large incentive for Docker's adoption was to get around the dynamic linking hell that is present in most modern Unix-

It's been said several times before that a large incentive for Docker's adoption was to get around the dynamic linking hell that is present in most modern Unix-likes. It's funny the author mentions a "world without linkers" with my posting of an article about the TAOS operating system today. Go look there if you want some primers on achieving that. That said, the author greatly oversells Docker's novelty.

pjmlp 11y ago
Yeah, I see that a lot nowadays, it is what I get being an old IT dog. Get UNIX containers, copy them with a sprinkle of FOSS and suddenly they are all the rage everywhere.
- tinco 11y ago
  Maybe you old dogs should've barked a bit louder because the way we used to manage systems and system environments before docker was plain ridiculous. No one ever told me to use containers, I don't even know of any pre-docker technology that allows me to do easily what docker allows me to. We used to do Chef scripts that are fed json configuration files that render configuration template files that installed loads of software into a completely bloated environment. Now we just have a simple bash script that provisions the machine, which means it sets up the network, firewall, sets up docker some monitoring, a configuration daemon (etcd) and then runs the orchestrator (in a docker container of course). And then from that point on, all operations are in the container world. You build a new production container, push it to the private registry, and tell the orchestrator to redeploy a service. Was that workflow even possible before docker? Using FOSS? I get angry just thinking about how we used to do it.
  - pjmlp 11y ago
    We old dogs don't mind paying for software. That was the only option when we started working. HP-UX vaults were already available in 2000. One of the reasons of Tru64 existence was to provide a high safety UNIX environment. Aix had its containers since ages. I can list many other UNIX and mainframe examples.
    - digi_owl 11y ago
      mainframe That may be the real reason. Most people working on server these days may well only have heard about mainframes as something close to myths, much less actually interacted with one in a production environment.
    - tinco 11y ago
      Well if they're all paywalled-off that sort of explains why I wouldn't have heard of them. Still a bit weird that apparently they were such a good idea many corporations used them, but none of them had popular Linux/BSD alternatives, even when isolation tech has been in the OSS OS'es for ages.
      - vezzy-fnord 11y ago
        FreeBSD had the first FOSS alternative with jails, then Solaris with zones. In the intermediate Linux had OpenVZ, but that was a much different container model and required kernel patching.
        tinco 11y ago
        So if a typical BSD sysadmin would set up a Rails website, would he create one jail for the application server, one jail for the SQL server, then set up firewall rules so that the app server could reach the SQL server and that traffic to the host would be forwarded to the app server?
        citrin_ru 11y ago
        There is more than one way to do this and jail per application is one of then. May be not most popular, but often used.
  - amirouche 11y ago
    you are a bit provocative for a start. Also what you describe does apply to vm.
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.

pjmlp 11y ago

Yeah, I see that a lot nowadays, it is what I get being an old IT dog. Get UNIX containers, copy them with a sprinkle of FOSS and suddenly they are all the rage everywhere.

tinco 11y ago
Maybe you old dogs should've barked a bit louder because the way we used to manage systems and system environments before docker was plain ridiculous. No one ever told me to use containers, I don't even know of any pre-docker technology that allows me to do easily what docker allows me to. We used to do Chef scripts that are fed json configuration files that render configuration template files that installed loads of software into a completely bloated environment. Now we just have a simple bash script that provisions the machine, which means it sets up the network, firewall, sets up docker some monitoring, a configuration daemon (etcd) and then runs the orchestrator (in a docker container of course). And then from that point on, all operations are in the container world. You build a new production container, push it to the private registry, and tell the orchestrator to redeploy a service. Was that workflow even possible before docker? Using FOSS? I get angry just thinking about how we used to do it.
- pjmlp 11y ago
  We old dogs don't mind paying for software. That was the only option when we started working. HP-UX vaults were already available in 2000. One of the reasons of Tru64 existence was to provide a high safety UNIX environment. Aix had its containers since ages. I can list many other UNIX and mainframe examples.
  - digi_owl 11y ago
    mainframe That may be the real reason. Most people working on server these days may well only have heard about mainframes as something close to myths, much less actually interacted with one in a production environment.
  - tinco 11y ago
    Well if they're all paywalled-off that sort of explains why I wouldn't have heard of them. Still a bit weird that apparently they were such a good idea many corporations used them, but none of them had popular Linux/BSD alternatives, even when isolation tech has been in the OSS OS'es for ages.
    - vezzy-fnord 11y ago
      FreeBSD had the first FOSS alternative with jails, then Solaris with zones. In the intermediate Linux had OpenVZ, but that was a much different container model and required kernel patching.
      - tinco 11y ago
        So if a typical BSD sysadmin would set up a Rails website, would he create one jail for the application server, one jail for the SQL server, then set up firewall rules so that the app server could reach the SQL server and that traffic to the host would be forwarded to the app server?
        citrin_ru 11y ago
        There is more than one way to do this and jail per application is one of then. May be not most popular, but often used.
- amirouche 11y ago
  you are a bit provocative for a start. Also what you describe does apply to vm.

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.