Having almost no experience with Docker myself, I unfortunately don't have much in the way of worthwhile technical input on this.
That said, I really do want to encourage this conversation. Installation of GNU Radio on one machine can be a pain for many people, and doing it on many machines over a network can be extremely difficult. I'm very interested in what Docker could do for us in terms of accessibility and administration. Cheers, Ben On Wed, Apr 13, 2016 at 2:31 PM, Nicholas McCarthy <namcc...@gmail.com> wrote: > Sorry I'm a few days late to the Docker party (and I don't have the > original thread at hand). > > Thanks, Stefan, for sharing your work. I want to share something similar > I worked up for my stack when Martin released pybombs2 and exposed me to > the "deploy" function. > > https://hub.docker.com/r/namccart/pybombs > https://hub.docker.com/r/namccart/pybombs-dev > > All the stuff is on github, including a grc docker using the local X11 > setup (as Jonathan described) with this pybombs install image. > > https://github.com/namccart/docker_grc.git > > 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. > > 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. > > _______________________________________________ > 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
