Gregory- > On Mon, May 9, 2011 at 2:59 PM, Andrew Lentvorski <bs...@allcaps.org> wrote: >> No embedded engineer who values his job will touch a GPL piece of code with >> a 10 foot pole. Â Period. > > and these are folks who will be out-competed in the marketplace by > competitors who are more agile and less phobic.
That sounds more wish than reality. For example, Apple is hardly being out-competed for being closed. Andrew makes an excellent point -- for-profit entities will avoid GPL if it means placing their code of value into the public domain. They will use GPL code when it saves time/cost and continue to find ways to mix and match with binary-only modules, physical separation across a bus or between dissimilar chips (or cores within an SoC), and other ways to "box" their proprietary code. Discussion about how to solve this within GNU radio is useful... could user-defined processing blocks be added that run on a GPU accelerator? Could a version of the USRP be made available that contains an OMAP or other device that would allow substantial user-defined baseband processing? Basically, some place to insert in the data flow user-defined code that has no GPL dependency. Documented reference examples showing how to do this would bring more users to GNU radio. -Jeff Over time, , whateverGPL whenever they can an > > [From the original article] >> Conversely, the DSA community seems to want to keep reinventing >> solutions. Every year we see demos that are slightly more polished >> and maybe a bit more expansive than the previous year's, but we still >> aren't really seeing huge leaps and bounds in the technology that I >> think we could and should be seeing. > > The obvious explanation is that there isn't actually a market in this space > people build things here in order to demonstrate how smart and capable > they areâ advancing the art is _hard_ and isn't strictly necessary > for just showing that you know how to build yet another slightly better > wisbang. > > > Marcus D. Leech wrote: >> I think there's a significant community out there that learned DSP >> techniques inside the envelope of Matlab/Simulink, and that's what >> they're comfortable with. To change this, Gnu Radio has to appear >> in more places in academia, so that graduating engineers have already >> been exposed to it, and find it "natural". > > One positive thing here is that python (esp with scipy/numpy) has been > aggressively replacing matlab/octave in many areas. It seems that > that this has gone slower RF DSP area, but this shouldn't be surprising > because there is a larger dependency on canned DSP objects than in > some other areas. > > > > Personally, I don't find the adoption curves surprising. The entry cost > for GNURadio + USRP are low compared to traditional tools, but those > who could afford those are mostly already comfortable with the toolset > they already know. The entry costs are very high compared to pure > software activities or heavily commodity activities. If someone is > doing development of high level communication systems using standard > ethernet $20 off the shelf 802.11 gear then the cost (in terms of time > and hardware) of doing _anything_ with GNURadio are basically astronomic. > (And they would still be even if the USRP were free, though less so) > > _______________________________________________ > 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
