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.

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.

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.

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.

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.

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?

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.

    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.

you are a bit provocative for a start. Also what you describe does apply to vm.

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.

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.

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).

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.

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.

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.