Thank you for pointing that out.
I have added a disclaimer to the repository:
This is AI-generated code. The developer has a neurological condition
that makes it impossible to use and learn traditional programming. The
developer has put in a significant effort. This code might not work
properly. Use at your own risk.
This code has not been reviewed by professional coders, it is a large
task. If there are tests available in the codebase, please review those.
Den 13.12.2025 13:32, skrev Marcus Müller:
> Hey Håken,
>
> > From what I can tell of the code, it is not "toy code ".
>
> But that's the whole thing here: No matter whether you yourself can
> tell, it really is toy code. Your "hard decision decoder" is not a
> decoder at all, your cryptography is broken beyond what an LLM can
> randomly repair based on feedback from a third party and so on.
>
> I like that you use the wording "toy code". I think what is happening
> here is that you're toying with LLMs to generate code for you, and
> you're considering that a good entertaining way of building something.
> And: I somewhat get it! That's a cool way of experimentation! I think
> you might benefit more if you did *smaller* things, because clearly,
> the code you generate isn't understood by you (to a very large degree,
> at least).
>
> And: you do have to realize that I, and others, looking at the forks
> of project on your github account, do need to read your code when you
> send PRs, and that if you publish a project like this, you are
> actually harming people who think it works. It doesn't, and
> specifically you throwing broken cryptography into projects endangers
> people who would actually rely on it.
>
> That's why I'll have to say this:
> I do value every would-be contributor to the GNU Radio project,
> including you! That's why I so enthusiastically replying to your first
> email.
> But when you do a "Feedback Request", that's a big ask. That's
> actively sinking hours. I've been contacted by **multiple** developers
> who now also have looked at your code. That means you burned through a
> couple Thousand norse kroner worth of "consulting" time, if you want
> to think of it in monetary terms (I prefer not to).
>
> So please don't be sad if I say this:
>
> Dear Håken,
>
> your code is autogenerated and doesn't do what you think it does. SDR
> is a rich field, and it requires not only writing of code that looks
> plausible and works on the tests that the same machine that wrote the
> code adds when you ask it to add tests.
> It actually requires understanding what you're implementing there.
>
> Your email read plausibly much like you understood a bit of what
> you're doing. I understand now that this "sounding plausible" was me
> falling for the usual "LLM-generated confidence" trap. That's on me –
> I just wasn't expecting it on the mailing list.
>
> So, I do apologize for the harsh tone, but will insist that you
> understand that sending code for review that you didn't have the time
> or capacity to **fully** understand yourself is not a *contribution*,
> but a *detraction*.
>
> I don't think you realize that. But in the GNU Radio project, I merge
> no code at all that I haven't *fully* understood (there is exceptions,
> if someone who is trusted by the project knows the specific area
> better, I can defer understanding every single line to them, but no
> line goes into the code base that isn't understood).
> If you don't understand (not even having written it) the code you're
> sending, then I still have to. That means you asking an LLM to write
> 1000 lines of code in a few hours is going to cost an actual expert
> more time than you spent on this to review stuff.
>
> That is not sustainable, especially because you generate code you
> don't actually seem to have need for yet, you just want to "wish it
> into existence", and LLMs betray you into believing they can do that
> for you. But they just make you take useful human time.
>
> Best regards,
> Marcus
>
>
>
> On 2025-12-12 6:29 PM, Håken Hveem wrote:
>>
>> Sorry. I never intended any harm. I use AI assisted programming due
>> to a neurological issue, it makes it impossible for me to program.
>> At least I know how to use the tool correctly and test it.
>> From what I can tell of the code, it is not "toy code ".
>>
>>
>> Den 12.12.2025 17:25, skrev Marcus Müller:
>>> Hi Håken, dear Community,
>>>
>>> oh no, I just got an LLM-generated reply to my (high-effort) reply
>>> to this email, and realized this is the same user that tried me to
>>> get a vibe-coded cryptographic module(!!!) merged upstream, then
>>> didn't even understand that no matter how much automatedly generated
>>> fuzzing you throw at things, if that doesn't actually test
>>> functionality, it's worthless.
>>>
>>> Ok, not going to bother with this module or your code in general
>>> anymore. Taking my email and pasting it into a chatbot to give me,
>>> in a single email,
>>>
>>> - "You're right to be curious",
>>> - "You're exactly right about the trade-off.",
>>> - "You've identified a real issue!",
>>> - "You're correct",
>>> - "You're absolutely right",
>>> - "You're right to question it."
>>>
>>> That degree of unmitigated LLM appeasement bullshit is not only sad,
>>> that's actively insulting to me. Sorry, I can't put this in any
>>> nicer terms. You're sending an email with questions, and once
>>> someone answers them, you take their reply, without having asked
>>> them, feed them into an LLM, spending about none effort on
>>> understanding the answers you've gotten at all, and send the reply
>>> to me, *as if that was an actual effort on your end*.
>>>
>>> If I wanted to chat with a large language model, I would. I don't
>>> need you to sit between a multi-billion dollar company's service and
>>> me and copy and paste text.
>>>
>>> I invest my time in this projects for *the humans using GNU Radio*.
>>> I don't know why you conjure this digital noise, but it's not
>>> productive. Especially because you're clearly pushing for terrible
>>> cryptographic decisions, I can't decide whether this is just gross
>>> incompetence on your end, or whether you're trying to covertly
>>> introduce broken cryptography into FOSS projects. The more of your
>>> filler projects I see, the more I tend towards the latter. If you're
>>> trying to poison the well here, please do go away.
>>>
>>> I decide how I spend my time on GNU Radio trying to help the
>>> community, the code base, and the long-term ecosystem development.
>>> Assuming you do this out of positive intent:
>>> You don't seem to realize that throwing vibe coded / LLM-generated
>>> nonsense at the community actually consumes our human resources. I
>>> sure as hell am *less* happy to volunteer my time working on GNU
>>> Radio after this interaction.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On 2025-12-12 4:00 PM, Marcus Müller wrote:
>>>> Hi Håken!
>>>>
>>>> That sounds very exciting! I haven't had time to look at your
>>>> source code, I'd especially be interested in your synchronization
>>>> methods and your choice of LDPC codes (we're deep into the "short
>>>> code length for limited latency" vs "code effectiveness" tradeoff
>>>> area here!)
>>>>
>>>> You're using ChaCha20, which is a stream cipher, right? That's
>>>> interesting because if you lose a single ciphertext block, say, to
>>>> a single uncorrectable bit error after FEC, then you need a way of
>>>> continuing to work. How does that work? Do you keep multiple
>>>> Key/Nonce pairs around and round-robin between a larger number of
>>>> ChaCha20 instances, to give you some leeway to continue to decode
>>>> OPUS while the receiving end asks for a keystream reinitialization?
>>>>
>>>> To kick off a bit more discussion, let me quickly answer your
>>>> questions to the best of my abilities:
>>>>
>>>>> 1. *Channel modeling:* Are the GNU Radio fading channel models
>>>>> (Rayleigh/Rician)
>>>>> representative of real-world mobile conditions, or should I
>>>>> expect different results
>>>>> on-air?
>>>>
>>>> They are what they say on the box :) It's hard to say whether
>>>> Rayleigh or Rician fading describes the channels you are aiming at.
>>>> Intercontinental HF links are different than indoors 5.8 GHz channels!
>>>> So, you need to define your use case first.
>>>>
>>>>> 2. *LDPC implementation:* I'm using hard-decision decoding for
>>>>> simplicity. For those
>>>>> who've implemented soft-decision LDPC in GNU Radio, what's the
>>>>> practical performance
>>>>> gain (measured, not theoretical)?
>>>>
>>>> That depends on very many factors, mostly on decoder design, block
>>>> length and maximum iteration count.
>>>>
>>>> I'm assuming you're just using the belief propagation sum-product
>>>> decoder that is in gr- fec? That does do soft decoding, you'd need
>>>> to pass in soft-bit RX values, though.
>>>>
>>>> It's really been a while since I thought about FSKs higher than
>>>> 2-FSK (that aren't differnetial).
>>>> Gut feeling here says that 4-FSK it's a pretty suboptimal use of
>>>> signal power.
>>>> I suspect that the first thing you'd do is drop the FSK approach
>>>> there, and go for a modulation scheme that allows for soft-bits
>>>> where, at least in AWGN, the entropy per bit is a bit better
>>>> behaved? But I'm really swimming dangerously close to the edge of
>>>> my channel decoder knowledge there.
>>>>
>>>>> 3. *Frequency offset:* The ±1 kHz sensitivity is possible
>>>>> concerning.
>>>>
>>>> Is it? What carrier frequencies are you aiming at? What are your
>>>> synchronization options?
>>>> Let's start with some back-of-envelop calculations here: You're
>>>> aiming at a 8000 b/s rate, using a r=2/3 code that's 12000 b/s
>>>> code, using 8-FSK, that's 4 kSym/s.
>>>>
>>>> Unless you're overly wasteful with your FSK spacing, that's a
>>>> rather narrow channel, and tolerating 1/4 of the symbol rate as
>>>> frequency offset is rather phenomenally good!
>>>>
>>>> Hence, recommendation to describe your current frequency
>>>> synchronization in more detail. You're clearly doing something
>>>> (else much less than a quarter-symbol rate frequency error should
>>>> lead to breakdowns) right already!
>>>>
>>>>> Has anyone
>>>>> implemented effective AFC for FSK in GNU Radio?
>>>>> Recommendations for libraries or
>>>>> approaches?
>>>>
>>>> Depends on what you're currently doing, and what your framing,
>>>> pilot, preamble, and system synchronization structure (is this just
>>>> one-way? Or can both ends agree on corrections?) are.
>>>>
>>>>> 4. *Performance validation:* How do simulation results typically
>>>>> compare to hardware
>>>>> testing in your experience?
>>>>
>>>> I think you'll realize that the only possible answer to this is "it
>>>> depends" :D
>>>>
>>>> > What factors cause the biggest discrepancies?
>>>>
>>>> The things you don't expect :) Sorry! This is a bit broad. As said,
>>>> synchronization and system aspects are often more relevant than
>>>> textbook knowledge would suggest, but I clearly don't know what
>>>> background you're doing this from, and hence, what you've covered
>>>> already.
>>>>
>>>> Best,
>>>> Marcus
>>>
>>
>
No comments:
Post a Comment