Docker container

[Sterling Hughes <st...@gmail.com>]

Hey,

I\u2019ve been noticing a bunch of issues cropping up recently with our 
Docker container, that seem to center around unusable speed of 
compilation.  I\u2019m wondering if there is a way to speed this up?

If we can\u2019t speed up docker-container based compilation: I think we 
need to de-emphasize it, and remove it as the first and recommended 
installation option for our toolchain.  Perhaps provide a very big 
warning about compilation speed and put the instructions on a Wiki page 
and point to them from docs, but don\u2019t include it in official docs?

I\u2019d be interested in other opinions, especially those of Windows 
users.  Are their any newt-Docker-Windows-devotees out there? :-)

Sterling

Re: Docker container

[Cris Frusina <cr...@frusina.com>]

Hi Sterling,

Although it's slow it provides windows users a way to get started easily. Installing a Ubuntu VM on Windows doesn't speed up the compile speed considerably in my experience and it's a more complicated install. 

Also the new version will have multi thread build capability so that should speed up compile time.

Having a warning that compile speed might be slow on Windows is a good idea as users will expect it and not think it's a bug. 

That's my 2 cents having used this on a Windows computer.

Cris


> On Jan 22, 2017, at 2:50 PM, Jacob Rosenthal <ja...@gmail.com> wrote:
> 
> I do like the idea of the docker btw.
> 
> Even without newt compile, one thing I was hoping to use it for was newtmgr
> for bluetooth transport as apparently this is unsupported on osx atm
> (though I cant find a link to why.. anyone?)
> 
> 
> On Sun, Jan 22, 2017 at 12:40 PM, Sterling Hughes <
> sterling.hughes.public@gmail.com> wrote:
> 
>> Hey,
>> 
>> I’ve been noticing a bunch of issues cropping up recently with our Docker
>> container, that seem to center around unusable speed of compilation.  I’m
>> wondering if there is a way to speed this up?
>> 
>> If we can’t speed up docker-container based compilation: I think we need
>> to de-emphasize it, and remove it as the first and recommended installation
>> option for our toolchain.  Perhaps provide a very big warning about
>> compilation speed and put the instructions on a Wiki page and point to them
>> from docs, but don’t include it in official docs?
>> 
>> I’d be interested in other opinions, especially those of Windows users.
>> Are their any newt-Docker-Windows-devotees out there? :-)
>> 
>> Sterling
>> 

Re: Docker container

[Jacob Rosenthal <ja...@gmail.com>]

I do like the idea of the docker btw.

Even without newt compile, one thing I was hoping to use it for was newtmgr
for bluetooth transport as apparently this is unsupported on osx atm
(though I cant find a link to why.. anyone?)


On Sun, Jan 22, 2017 at 12:40 PM, Sterling Hughes <
sterling.hughes.public@gmail.com> wrote:

> Hey,
>
> I’ve been noticing a bunch of issues cropping up recently with our Docker
> container, that seem to center around unusable speed of compilation.  I’m
> wondering if there is a way to speed this up?
>
> If we can’t speed up docker-container based compilation: I think we need
> to de-emphasize it, and remove it as the first and recommended installation
> option for our toolchain.  Perhaps provide a very big warning about
> compilation speed and put the instructions on a Wiki page and point to them
> from docs, but don’t include it in official docs?
>
> I’d be interested in other opinions, especially those of Windows users.
> Are their any newt-Docker-Windows-devotees out there? :-)
>
> Sterling
>

Re: Docker container

[Roman Shaposhnik <ro...@shaposhnik.org>]

On Sun, Jan 22, 2017 at 11:40 AM, Sterling Hughes
<st...@gmail.com> wrote:
> Hey,
>
> I’ve been noticing a bunch of issues cropping up recently with our Docker
> container, that seem to center around unusable speed of compilation.  I’m
> wondering if there is a way to speed this up?

Has anyone looked into why is it slow? Knowing nothing about the details ;-)
still makes me feel like betting $5 that it'd be related to the I/O.
If that's the
case one thing to try would be to toggle -v

Thanks,
Roman.