Okay! all great then.
Now I want us to iterate upon the suggested plan / 'road-map'. I have
hinted that we can use ADD. That is another kind of improvement. I
think it will save us some considerable overheads, if we move around
our code a bit. And actually not need to make any special s6-base
imag
> John, I agree with all of your points (and reservations) here in last message.
>
> And in retrospect, sorry for being a bit argumentative over that
> entrypoint aspect of our discussion. You know, more people tend to
> agree with your way of doing things than mine. But both approaches
> have the
> Well you are then neglecting to see 2 other benefits which i neglected
> to mention anywhere previously:
>
> 1) Is that anyone can just look in my Dockerfile and see the default
> tvheadend arguments as-is. Without needing to go around chasing them
> being embedded in some script (when only Dock
On Fri, Feb 27, 2015 at 5:29 PM, John Regan wrote:
> Quick preface:
>
> I know I keep crapping on some parts of your ideas here, but I would
> to reiterate the core idea is absolutely great - easy-to-use images
> based around s6. Letting the user quickly prototype a service by just
> running `dock
On Fri, Feb 27, 2015 at 5:08 PM, John Regan wrote:
>> Let me explain my point by an example:
>>
>> I am writing an image for tvheadend server. The tvheadend program has
>> some default arguments, which almost always are:
>>
>> -u hts -g video -c /config
>>
>> So then after that we might append use
Quick preface:
I know I keep crapping on some parts of your ideas here, but I would
to reiterate the core idea is absolutely great - easy-to-use images
based around s6. Letting the user quickly prototype a service by just
running `docker run imagename command some arguments` is actually a
*great*
> Let me explain my point by an example:
>
> I am writing an image for tvheadend server. The tvheadend program has
> some default arguments, which almost always are:
>
> -u hts -g video -c /config
>
> So then after that we might append user-specifig flags. Which for my
> personal use are:
>
> -
On Fri, Feb 27, 2015 at 1:10 PM, Dreamcat4 wrote:
>> * Once there are 2+ similar s6 images.
>> * May be worth to consult Docker Inc employees about official / base
>> image builds on the hub.
>
> Here is an example of why we might benefit from seeking help from Docker Inc:
>
> * Multiple FROM im
On 26/02/2015 19:37, Olivier Brunel wrote:
saying I feel this option makes sense on its own, not just to reduce the
number of executable to call, but because s6-envdir is used to define an
environment, having a way to guarantee what said environment will be
seems a good/logical thing.
Yes, it
> * Once there are 2+ similar s6 images.
> * May be worth to consult Docker Inc employees about official / base
> image builds on the hub.
Here is an example of why we might benefit from seeking help from Docker Inc:
* Multiple FROM images (multiple inheritance).
There should already be an ope
On Fri, Feb 27, 2015 at 10:19 AM, Gorka Lertxundi wrote:
> Dreamcat4, pull request are always welcomed!
>
> 2015-02-27 0:40 GMT+01:00 Laurent Bercot :
>
>> On 26/02/2015 21:53, John Regan wrote:
>>
>>> Besides, the whole idea here is to make an image that follows best
>>> practices, and best pract
On Thu, Feb 26, 2015 at 11:40 PM, Laurent Bercot
wrote:
> On 26/02/2015 21:53, John Regan wrote:
>>
>> Besides, the whole idea here is to make an image that follows best
>> practices, and best practices state we should be using a process
>> supervisor that cleans up orphaned processes and stuff. Y
Dreamcat4, pull request are always welcomed!
2015-02-27 0:40 GMT+01:00 Laurent Bercot :
> On 26/02/2015 21:53, John Regan wrote:
>
>> Besides, the whole idea here is to make an image that follows best
>> practices, and best practices state we should be using a process
>> supervisor that cleans up
13 matches
Mail list logo
