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

Reply via email to