[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

From: Marcus Müller
Subject: Re: Gnuradio 3.8 on a Raspberry pi 4 B?
Date: Thu, 25 Nov 2021 23:52:46 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0

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,

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]