Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Marcus Müller]

Hi Lamar!

On 25.11.21 14:39, Lamar Owen wrote:
> On Nov 25, 2021 8:15 AM, Marcus Müller <mueller@kit.edu> wrote:
>
>     ...
>
>     Honestly, a RPi4 would just go to waste with me! If you want to crowdsource 
> one for the
>     greater good of the SDR community, I'd say: Radioastronomy outreach, or ham 
> radio, that's
>     the two things I'd think a RPi4 would make the biggest impact.
>
> Radio astronomy outreach is PRECISELY what Glen is doing, and what the rapid changes in 
> GNUradio are making difficult.  

I don't want to get into this again, honestly, we have like six or seven threads on this 
mailing list.
What works today will continue working as long as the hard- and software it is based on 
exists and functions. Nobody is asking Glen to delete his code (quite the opposite, share 
with us so we can help you)!

Thing is: soft- and hardware we work on is subject to change. We're not the one choosing 
that. What I did 2018–2021ish is to make sure GNU Radio works in 2021, on systems you 
install 2021. It does. Had we kept everything the way Glen wished we, then it wouldn't, 
and we would have not seen the explosion in active contributors that now actually do 
something with GNU Radio that it couldn't do before.

It's really that simple: Stillstand and technical and community Death, or Progress and 
Breakage. It's a balance to strike, which is why with every release, the poor Maintainer 
goes and looks into their crystal ball, to see what they can improve without breaking the 
usability on reasonably old systems for the next release. We're really doing our best to 
*not* let GNU Radio die, so please understand that as much as I personally like what Glen 
does, it cannot define GNU Radio's speed. It literally mustn't, lest you want people to 
fork off GNU Radio and do something that actually moves forward. I've got a longer email 
in one of the other threads on this, but that's *exactly* what we had with the `next` 
branch during the later years of the great 3.7 stagnation. Fragmentation, a lack of 
perspective, and hence a reduced contributor base, which then led to need for *abrupter* 
chaos.

Luckily, you don't have to make a fork to get an old version of GNU Radio: you can just 
download, build and install an old version of GNU Radio :) Problem is, at some point you 
can, but none of the maintainers actually find time to do the same, so they know 
everything they do to that old version might break something in more or less subtle ways.
That's when as a maintainer, you, responsibly, publicly say that, no, sorry, we're no 
longer in a position to guarantee the quality of further software releases. And that's 
exactly what Jeff announced for 3.7: Hey, we haven't done anything to it for quite a 
while, we can't actually test what it does when we change something, we don't have the 
programmer and maintainer volunteer base to develop this version: it's outdated. Luckily, 
we did this after years after releasing 3.8, which very clearly was meant to be a version 
that should make the transition from 5 years of standstill to something that will still 
compile next year easier (Python2 compatibility, SWIG, GRC conversion features, nearly no 
code structure changes).

So, please, understand that I might get a bit frustrated by people portraying things like 
we're letting Glen stand out in the rain. Or that we do things "willy-nilly". We don't. We 
made sure he has migration options, multiple people are and have been offering help, 
people are actively trying to help him get his airplay running, even though it's a 
commercial product that's incompatible by its own choice with our software license. We 
have a fantastic release management (kudos to Jeff, but also to Josh for planning the next 
releases) and maintenance branch longevity for a project with this few people actually 
doing the codebase work. We've got *awesome* volunteers. Please don't scare them away!

Best regards,
Marcus

smime.p7s
Description: S/MIME Cryptographic Signature