Re: [Discuss-gnuradio] Why Isn't GNU Radio Used More?

[Marcus D. Leech]

On 09/05/2011 2:25 PM, Michael Dickens wrote:
> I often use GRC for simple tasks -- it's a LOT faster than writing Python scripts, and it 
> "just works" for these tasks.  Admittedly, these are simple -- such as reading 
> a file of audio data, adding in gain, and then both displaying a waterfall FFT and piping 
> the data to audio out.  I do agree that for any cutting-edge project what you write is 
> true, but if GNU Radio accumulates blocks over time GRC will eventually fit the needs of 
> that 90+% I keep talking about.  Of course, that ~10% will always remain, as they are the 
> cutting edge folks.
There's a growing expectation that Gnu Radio exists to provide 
functional blocks for *all parts* of your communications system.  I 
think that's
  a flawed model, and flies in the face of sound modularity 
principles.   There's an expectation that Gnu Radio handle "everything", 
and I just
  don't think that's a good model.  Gnu Radio, to me, is a DSP engine 
that happens to live on a general-purpose compute platform.  But it has
  become "sullied" over the years with "other stuff" unrelated to 
strictly-signal-path problems.  Attempting to shoe-horn "stuff" that isn't
  strictly signal-path oriented into Gnu Radio will cause both 
unnecessary bloat in the codebase, but more-importantly, it will cause 
people
  to suffer grief in that they're trying to use the wrong paradigm to 
solve the not-strictly-signal-path parts of their "solution".


> True, but it's an enormous class.  Maybe I'm too limited, but I cannot think of 
> a communication algorithm that can't be implemented graphically in GRC, somehow 
> (or the equivalent, via some combination of a data-flow graph and text command 
> line such as provided by Python).
See above.   The problem is that people want the Gnu Radio signal-path 
paradigm to solve problems that aren't necessarily directly signal-path
  related.  Strictly speaking, for example, none of the GUI stuff 
should be in Gnu Radio proper at all.  But it's awfully convenient.  The 
thinking that
  lead to non-signal-path processing inside Gnu Radio is, I would 
assert, a strong reason for people finding it "wanting"--they naturally 
expect
  that it does "everything".  Which it can't.  Hmmm, I wonder if a 
flow-graph is Turing complete?  Another example: HTML.  HTML can be used
  to solve a vast number of problems, and indeed rich "applications" 
have been constructed using HTML.  But (at least early versions of) HTML
  isn't Turing complete--it's not a complete programming paradigm, and 
so much functionality must necessarily be implemented outside of
  it.  I would assert that Gnu Radio is in the same category--it's a 
paradigm for managing mathematical data-flow. So, when you have a problem
  that falls outside of that model, you have to ask yourself: is it a 
flaw in the model, or a flaw in my reasoning about the applicability of 
the model
  to my application?   From what I've seen on the list over the last 
several years, a goodly chunk of "heartburn" on the part of newbie users is
  due to imperfect understanding of the model, and incorrectly 
assigning functional pieces to the flow-graph model.



> True, but that's OS-dependent and a nuisance.  Why not the dual-license 
> approach -- one as GPL and another that allows for local IP (the LGPL would 
> probably suffice)?  Again I don't know if the FSF would allow it, but there are 
> plenty of potential end-users who would benefit from this model. - MLD
I'm not an expert on licensing issues, which is why I've avoided them in 
the couple of small-scale commercial systems I've done with Gnu Radio as an
  underlying "engine".