Hi,

just recently, I got smacked in the head with an error that I have come to hate:

Unpacking replacement google-talkplugin ...
dpkg: dependency problems prevent configuration of google-talkplugin:
google-talkplugin depends on libc6 (>= 2.14); however:
Version of libc6:amd64 on system is 2.13-38+deb7u6.

I'm using Debian Wheezy and love the stability it offers, but I know that I won't be able to install this package unless I update the whole system.

Now every since investigating Docker, I imagined that it could be the solution for all the "this libc library is too old / too new for this software" problems or get software running on a distro that was not originally meant for it and saving you hours and hours of digging around forums to figure out how to make it work.

Here a few examples of what I imagine would save so much time:
run sofware like steam on Debian, just use a Ubuntu image container.
Run things that only works on Debian Jessie on Wheezy.

In the above case, the plugin is part of chrome. Now I would probably have to run Chrome too in the container too.

Now my question is, is this doable? What have been your experiences with this?

Does this work with stuff that connects to the hardware?
As an example, I have tried to compile wineasio for Debian Wheezy and it has been such a pain and so far I could not make it work. Kxstudio has a working and reliable wineasio.

Now I imagine to just run this in a kxstudio container. But wineasio connects to jack and jack connects to alsa and alsa of course to the hardware, can docker do such a thing?

Hmm, interesting. I seem to be the only person that has contemplated this so far.

So I will do some research and see if this works, and report back with a solution.

This might be a really super cool way to side step a lot of terrible problems we now have trying to make software run on a distro that it was not intentended for.

Docker might even eventually allow companies to package their software in docker so that it runs on all distros 100% surely.

For running Testing/Unstable software, you could use a chroot system:
https://www.debian.org/doc/manuals/d..._chroot_system

I do that already in some cases and I consider it ugly, since it is not really 100% contained.
Docker is much more cleaner in this respect and the images can be better packaged.

you can use LD_PRELOAD or LD_LIBRARY_PATH

Here is an interesting link:

https://github.com/noisecapella/docker-steam-pulseaudio

running steam in a docker container. Steam can be a total pain to setup, especially on Debian.

It is possible and actually quite easy. For Steam there are even pre-made containers available from Docker, including instructions gow to run them. It basically comes down to specify the correct bind-mounts in your Docker file to get it running (stuff like the X and Pulseaudio magic cookies and parts of the /dev tree).

Restrain your ego - most of the aware world has looked at docker for quite some time.

I would be to differ, I posted this a month and 6 days ago and nobody reacted, but so far 616 people read the post and even when I responded to my own post 3 days later with the "am I the only one?", nobody responded to that. Hardly a trivial "oh yeah, here are lots and lots of links, it has been done for years now, have you been living under a rock?"

So most of the world might have looked at docker, but not come up with solutions for the problem I described. I inherently is a great solution for the distro framentation on linux: For companies to release one version that runs on all Distros, guaranteed. Yes, it is wasteful, but many companies usually release statically linked stuff anyway, so no big change there.

And it would solve many of my problems and I'm sure other peoples too: I'm currently try to get wineasio working on Debian Wheezy, but after spending days, I am not closer to a solution. It works on KXStudio, so creating a docker container for wineasio based on Kxstudio would be a possibility that would surely work, but there are tricky questions that I have not found answers to so far:
how do you connect and integrate low level system access like to alsa or to the sound card? How do you let programs outside the container connect to for example jackd inside a container?

I don't know enough about docker yet to find a solution to it.

There is nothing more to it than bind-mounting the devices you need from the /dev tree to your container.
I don't know much about Jack, but it should either be similar to the soltuion above, or if it is network-based then just forward the ports to your host OS.

Strangely, I never even considered this before, though it's obvious. Always thought of it as a way to isolate network apps. Actually, this could be a far better way for commercial companies to deliver their software to linux. Currently the state of that is a mess.

Of course the old way, in my personal order of preference, was

1. best: grab the source package from testing/unstable or some other repo and rebuild an installable package on your system (debian makes this a 1 step process, very easy)
this works most of the time so long as the app doesn't have a lot of lib dependencies satisfied only in the other release, but usuall apt-get build-deps will give you what you need. This can screw up a release upgrade, though, so you have to uninstall all of this before doing dist-upgrade. I only do this for simple cli commands and what not.

2. build a minimal chrooted testing or unstable system on the file system. More work up front, but much cleaner. This is about what your're doing with docker here. The difference being you can slap the docker container on a thumb drive and run it elsewhere.