[takeda]

I'm not hiding that after I learned about Docker I became skeptic. It seems like yet another thing that people observed what Google was doing, and then implementing it wrong.

Google is using containers instead of VMs. This still provides security isolation and allows them to use resources more efficiently (VM has overhead where you need a whole OS for every instance).

This approach does not make much sense in public cloud, where you already run inside of VM and the overhead is really for Amazon not you. So I see Docker is now pivoting to be a package manager, but there are already tools that do that. You can argue that Docker is simpler but so was rpm when it started. As Docker will grow it will become more complex in order to support all functionality package format already provides. There might be an argument that you can run multiple Docker containers on a single host, but that's what processes are for.

There is change happening, and looks like cloud companies want to create "cloud os", I guess Docker is step toward that direction, but at current state in don't see it offering anything valuable to the organization that uses it.

[monkey26]

Docker as a package manager somewhat matches my use, and I think it does its job well. As the packager, I can just create one "package" that any Linux distribution running Docker can install, instead of creating packages for multiple versions of many different distributions.

[philips]

I think that container images will replace traditional package management in many cases. Package management in Linux has given us many great things:

1) Easy global mirroring of software using "boring" protocols like http and ftp

2) Cryptographic signing of the software so we can trust mirrors and systems that put users in control of who to trust.

3) Human significant package names that are easy to pull onto a host e.g. `apt-get install $name`

Where package management broke down:

1) Package collisions e.g. If I want to install a new custom build of python it replaces the host version and everything may break. The python3 v python2.6 problem.

2) Dependency namespacing. e.g. If I want rely on a non-official mirror to ship me whizbang project X they could also replace my libc by adding it to the repo because the names and versions collide.

Making sure that we hold onto the good three properties of package management while fixing the two problems is important for Linux moving forward. The last 15 years of Linux was dominated by the centralized package management system and a ton of hacks have developed to work around it when you need a new package or want to install custom software. This is why I spend so much time working on container image specs like appc and oci; I hope we can arrive at a good container image format for the next 15 years that everyone can rely on.

For examples see slide 6 forward here: https://speakerdeck.com/philips/rkt-and-the-need-for-the-app...

[takeda]

> 1) Package collisions e.g. If I want to install a new custom build of python it replaces the host version and everything may break. The python3 v python2.6 problem.

I'm sorry, but you hit my pet peeve when you used python as example. Python was written in a way that you can have multiple versions installed side by side and they all can work without problem. If you have a python3 package that is uninstalling python2.6 then its author screwed something up and I would be afraid to use it at all.

> 2) Dependency namespacing. e.g. If I want rely on a non-official mirror to ship me whizbang project X they could also replace my libc by adding it to the repo because the names and versions collide.

Is that still an issue? Zypper in OpenSuSE is quite smart and for each package it remember which repo it is from. It tries to satisfy dependencies without changing vendor, and prompts if only way to satisfy dependencies is to change vendor.

That said if an application requires different version of glibc much better would be to compile it statically, but even then glibc supposed to match your kernel version so you're still risking some incompatibilities.

[XorNot]

Static glibc doesn't work anymore. If you need the internet then you'll be pulling in the nss plugins anyway.

[davexunit]

GNU Guix is a package manager that solves those 2 problems while not sacrificing the 3 good properties. It also offers additional nice features like unprivileged package management, transactional upgrades/rollbacks, full system configuration management, and a tool that can be used like a language-agnostic virtualenv. Built-in Linux container integration is also on the way.

https://gnu.org/s/guix

[takeda]

What language is it in, why not use packaging from the language itself. It would be more likely to work across many different OSes not just Linux.

If it's a binary, why not compile it statically? That way it's a single file and it also will perform faster (using shared objects has overhead)

[philips]

Packaging in the language itself ranges from difficult to impossible for most non-trivial apps. Popular runtimes like python, node, and ruby have many extensions and packages that rely on C and share libraries. Because of that a compiled binary package will not be portable between machines or require that the machine you deploying to have a working compiler to build the C package from source. I have seen vast amounts of engineering effort invested into porting C code to slower "native" code just to make packaging work. With containers you can avoid the mess of trying to share the `/` filesystem namespace with the host and concentrate on getting your application working on a chroot that is portable between Linux kernel systems.

I 100% agree with the compile it statically thing. This is what many major internet properties likes Google do and I would argue part of why Go is so popular. But, it is hard for the vast majority of applications that expect to open files for assets and lack build systems for static compilation.