>
> I think it would be really helpful for the GNU Radio project to support a
>> standard, basic gnuradio docker install with uhd and grc enabled as well as
>> an example or two to demonstrate sane ways to run OOT modules on top of
>> that image. As Ben mentioned, Docker seems like a pretty energy-efficient
>> way to approach support for systems like Windows and OSX going forward.
>> Not having used boot2docker personally, I won't say that it's necessarily
>> time to retire the live usb image, but I think Docker may evolve quickly
>> into a pretty obvious replacement, if it hasn't already. I also appreciate
>> GNU Radio looking for ways to support users and potential users attempting
>> to build and deploy applications that reach beyond the immediate
>> environment of GNU Radio and its core devs.
>>
>
As far as OOT modules, that's easy. For instance, a Dockerfile for
gr-air-modes could look like this (this is untested, don't get any ideas):
FROM bistromath/gnuradio:3.7.8
MAINTAINER bistrom...@gmail.com version: 0.1
RUN apt-get install -y python-zmq
WORKDIR /opt/gr-air-modes
COPY . /opt/gr-air-modes
RUN mkdir build \
&& cd build \
&& cmake ../ \
&& make -j4 \
&& make install
...that's more or less the whole thing, although this particular example is
broken for a couple of reasons (no Qt in my base layer, other missing
prerequisites). It might be nice to include a Dockerfile template in the
OOT example. The nice part about doing OOT modules in this manner is that
Gnuradio users could potentially never have to compile Gnuradio -- just
write their OOT and base its Dockerfile upon a precompiled Gnuradio base
layer. Another benefit is bitrot is all but eliminated, as you're basing
your module on top of a versioned base layer rather than master.
>
>> One problem we have to face, though, is image size. I'm trying to tackle
>> that problem by compressing the install for transactions over the wire and
>> then uncompressing locally for applications (using pybombs2, of course).
>> This is all a little awkward for docker distribution, but lots of things in
>> docker are a little awkward. Developers could build on top by untarring
>> the prefix, pybombs installing extra recipes (possibly custom recipes) and
>> then using the deploy command again, all within the same Docker "RUN"
>> section. Locally, if you docker build applications beginning with the same
>> commands to untar the image, then all applications can take advantage of
>> that layer (you'll have to untar the base image only one time regardless of
>> how many applications use the base image). Alternatively, you can docker
>> run with cmd or entry set to untar the image (and then, presumably, you'll
>> want to commit the running container locally so you don't have to untar
>> again).
>>
>
>>
> Does anyone have a better idea for bringing image size down without making
>> it impossible to build and deploy OOTs? Those Bistromath images are pretty
>> tiny... I haven't really looked into the Alpine base image, either.
>>
>
The Docker image I put up on Docker Hub is small-ish because it only
includes these components (and their prerequisites):
-- * python-support
-- * testing-support
-- * volk
-- * gnuradio-runtime
-- * gr-blocks
-- * gnuradio-companion
-- * gr-fft
-- * gr-filter
-- * gr-analog
-- * gr-digital
-- * gr-channels
-- * gr-uhd
-- * gr-utils
-- * gr-wxgui
It could be a lot smaller if I removed the GR build files (292MB), GR
source files (88MB), and UHD source/build (200MB). That would cut it down
to somewhat more than half its current size. I like having them there
because if I'm working inside the environment I can compile changes
incrementally. For a pure deployment system, though, they're unnecessary.
It's possible, albeit messy, to build a Gnuradio distribution in layers and
tag the individual layers separately. Because each command in a Dockerfile
produces an incremental UFS layer, if you can break the compilation of
Gnuradio into separate commands for each component in the Dockerfile, then
you can tag the various incremental layers to build different composite
Gnuradio distributions. It's probably simpler just to provide a
"bells-'n-whistles" version and a "bare bones" version.
If you like, I can see just how small I can reasonably get things. I'd
argue, though, that a one-time, couple-of-GB download is a reasonable
compromise for the convenience of versioned distribution in all but niche
applications (embedded or offline come to mind). In other words, the
benefit of getting the wire size down probably doesn't outweigh the effort
for most people.
--n
>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
