> The idea is that with a docker-targeted s6 tarball, it should
> universally work on top of any / all base image.
Just to make things perfectly clear: I am not going to make a
special version of s6 just for Docker. I like Docker, I think it's
a useful tool, and I'm willing to support it, as in make adjustments
to s6 if necessary to ease integration with Docker without impacting
other uses; but I draw the line at adding specific code for it,
because 1. it's yet another slippery slope I'm not treading on, and
2. it would defeat the purpose of Docker. AIUI, Docker images can,
and should, be standard images - you should be able to run a Linux
kernel with init=YOURENTRYPOINT and it should just run, give or take
a few details such as /dev and more generally filesystems. (I don't
know what assumption a docker entrypoint can make: are /proc and
/sys mounted ? is /dev mounted ? is / read-only ? can I create
filesystems ?)
> If what Laurent says is true that the s6 packages are entirely
> self-contained.
It depends on what you mean by self-contained. If you compile and
statically link against a libc such as musl, all you need is the
execline and s6 binaries. Else, you need a libc.so. And for the
build, you also need skalibs.
It's unclear to me what format a distributed docker image takes.
Is it source, with instructions how to build it ? Is it a binary
image ? Or is it possible to distribute both ?
Binary images are the most practical, *but* they make assumptions
on the target architecture. Having to provide an image per target
architecture sounds contrary to the purpose of Docker.
> * re-write /init from bash ---> execline
> * add the argv[] support for CMD/ENTRYPOINT arguments
I can do that with Gorka, with his permission.
> * /init (probably renamed to be 's6-init' or something like that)
Why ? An init process is an init process is an init process, no
matter the underlying tools.
Also, please don't use the s6-init name. I'm going to need it for
a future package and I'd like to avoid possible confusions.
> * Can probably start work on the first bullet point (convert "/init"
> to execline) during this weekend. Unless anyone else would rather jump
> in before me and do it. But it seems not.
Hold your horses, Ben Hur. People usually take a break during the
weekend; give at least John and Gorka some time to answer. It's
John's initial idea and Gorka's image, let them have the final say,
and work on it themselves or delegate tasks as they see fit.
> * If Laurant wants to push his core s6 releases (including the docker
> specific one) onto Github. Then it would be great for him to make a
> "github/s6" org with Gorak, as new home for 's6', or else a git mirror
> of the official skanet.org.
I'm not moving s6's home. I can set up a mirror for s6 on github, but
I fail to see how this would be useful - it's not as if the skarnet.org
server was overloaded. (The day it's overloaded with s6 pull requests
will be a happy day for me.)
If it's not about pulling, then what is it about ?
(In case you can't tell: I'm not a github fan. Technically, it's a
good piece of software, git, at the core, with 2 or 3 layers of all your
standard bloated crap piled onto it - and it shows whenever you're
trying to interoperate with it. Politically, the account creation
procedure makes it very clear that github is about money first. The
only thing I like about github is the presentation, which is directly
inspired from Google. So, yeah, not much to save.)
--
Laurent
Received on Sat Feb 28 2015 - 10:58:33 UTC