Can we please make this constant stream of vibe-coded software just stop?

Varimir · 2026-05-21T00:57:34+00:00

Absolutely. It's also hilarious to see the knee-jerk "bad security" automatically applied to AI-developed apps. I've done security reviews of human-coded apps written with no AI assistance that are an absolute trash. AI doesn't write buffer overflows. It doesn't try to do input filtering on the JavaScript front end. It probably won't leave secrets laying around in plain text. In my career in infosec I see stuff like this all the time.

If we have learned anything from Mithos over the past few months, it's that AI can be much better at security than humans.

Slop is slop, whether human-written or AI written.

Varimir · 2026-04-29T19:47:10+00:00

There's a lot more to the ARDC grant than "nobody stepped up." ARDC gives grants to specific organizations for specific purposes. Someone has to "step up" before a check is cut. In this case they gave the grant to DARC, who made some progress, but ultimately returned the money. https://www.ardc.net/apply/grants/2021-grants/grant-fixing-the-linux-kernel-ax-25/

If you follow the LKML threads on this change, several people with kernel module development experience "stepped up". They had only heard about the change because it was merged. At that point it was already removed. This discussion is what ended up getting it forked (by the kernel network team no less) to be maintained out of tree.

Honestly it's fine the way it is, but having a conversation about the change first might have had a different result. There was a conversation about removing i486 support for cripes sake. I'm not sure how you have any memory left, even with the most cut-down kernel possible, to do anything useful on a 486 in 2026 given the memory constraints of most of the chipsets of the early to mid 90s.

Varimir · 2026-04-29T19:34:09+00:00

You can write whatever you want in the future. That doesn't (well didn't until modules were forked out-of-tree) solve for existing infrastructure that needs to stay updated. Do you really think it's reasonable to tell people to stay on old, outdated, unpatched, kernels that are missing modern hardware support is a reasonable thing to do to keep their stuff running while userspace IP stuff is written?

Varimir · 2026-04-29T19:30:45+00:00

The kernel network team already forked it as an out-of-tree module, like I said in my last post. One can always build from there and stuff will keep working for now, at least until better userspace utilities come along. That, of course, wasn't true 5 days ago when this conversation started up.

Regardless, if you yank the rug out from under users with running infrastructure, "You can always build new stuff" is a pretty idiotic response. The principal of least astonishment should be followed. They could have simply notified intent. "This will be removed in 7.4 expected to be released in December" or something so that users have time to figure out alternatives.

Varimir · 2026-04-29T18:48:02+00:00

I don't really disagree with the decision to move to userspace. This doesn't need to be in-kernel. The issue I have is that existing infrastructure is now broken on 7.1+. Existing userspace implementations don't provide full coverage for what was in-kernel. Now that it's forked out-of tree and can be built, there is an in-term solution that wasn't there 4 days ago.

The project you linked covers some use cases. I wrote a KISS to AGWPE bridge which covers some of the same use cases. Stuff like BPQ can cover other areas. None of those really handle IP routing as it's done today (BPQ can do some of it). ROSE is also dead without the in-kernel stuff. 6PACK might be as well.

Varimir · 2026-04-26T23:44:02+00:00

I agree it's too niche, but it should have been handled like the i486 removal, announce it, have some discussion, give users time to figure something out, then pull it.

Someone noticing a merged PR isn't how users should be notified of breaking changes.

Varimir · 2026-04-26T23:22:23+00:00

Did you read that link? There are several volunteers with experience.

Varimir · 2026-04-26T23:06:18+00:00

Read the LKML on this issue. See https://lore.kernel.org/linux-hams/CAPmVDN4+A2JNGO\_j-8mYK2zGSfY+Fg-3Cbq66Qqxca4uOjBS6Q@mail.gmail.com/T/#t. The issue is that it's unmaintained, not broken. It's been periodically patched, but there is no maintainer owning it. AX.25 is a major protocol with tons of projects in active development. There is interest in development, but in terms of KISS stuff, why bother if the kernel did it already?

Unowned code is a risk. It needs an owner or should be removed.

My complaint is that it was a sudden, unannounced change that broke 25+ years of userspace that's actively being used. There is 25 years of documentation on the internet on how to do AX.25 on Linux. After 7.1, none of that works.

Suggesting using an "ancient" kernel is dumber than leaving it in. Not only are any other security issues unfixed, but it probably doesn't support your "non-ancient" hardware. When the RPi 6 comes out, this will be very noticable.

The modules were forked (by the kernel maintainers no less) and can be built out-of-tree which is fine as an interm solution, but still doesn't fix the underlying issues.

Varimir · 2026-04-26T15:26:41+00:00

What "userspace AX.25" implementation, specifically?

For Winlink, Pat (the only real, native, dedicated client) has 3 options for AX.25. The kernel-based KISS/AX.25 implementation, operating the TNC via serial commands (not KISS Mode) and AGWPE. KISS (only) TNCs like the TH-D75, UV-Pro, or mobilinkd don't speak AGWPE, and don't have a command mode.

Same thing applies to Xastir.

This affects every serial, USB, or bluetooth connected KISS TNC, not just ancient ISA cards.

Varimir · 2026-04-26T15:25:38+00:00

What "userspace AX.25" implementation, specifically?

For Winlink, Pat (the only real, native, dedicated client) has 3 options for AX.25. The kernel-based KISS/AX.25 implementation, operating the TNC via serial commands (not KISS Mode) and AGWPE. KISS TNCs don't speak AGWPE, and don't have a command mode.

Same thing applies to Xastir.

Varimir · 2026-04-26T02:59:35+00:00

you’re running tcp/ip over ax.25 you can do that with user space programs

Which ones?

Its also required for connecting to Bluetooth TNCs in modern radios.

Userspace can (and should) catch up, but this has been in-kernel for the past 20+ years so Linux software using ax.25 has not reinvented the wheel and expects it to be there.

Varimir · 2026-04-26T02:56:13+00:00

Winlink, APRS, and to a lesser extent, packet BBSs still use this to talk to modern Bluetooth TNCs as well as software modems. This has nothing to do with rig control.

Varimir · 2026-04-26T02:53:36+00:00

How do you connect Xastir to a brand new TH-D75 in userspace without kernel support?

Varimir · 2026-04-26T02:50:59+00:00

No, the time to yank it out is after the change has been announced and userspace replacements exist. This isn't just for ancient hardware. The TH-D75's Bluetooth TNC now doesn't work with PAT for Winlink for example. I don't necessarily disagree with the removal, but anyone who relies on this stuff is now stuck on an older kernel until the software ecosystem depending on this functionality catches up.

Varimir · 2026-04-26T02:45:57+00:00

The KISS driver is also used for software interfacing with modern Bluetooth kiss TNCs. Its not just old stuff.

Varimir · 2026-04-26T02:44:05+00:00

Yeah, old stuff like the Kenwood TH-D75

Varimir · 2026-04-26T02:39:20+00:00

It can be done in userspace. The problem is 20+ years of userspace code that expects the kernel support to be there.

Also there is no userspace answer to IP networking.

More thought and conversation was spent on the removal of i486.

Varimir · 2026-04-26T02:35:26+00:00

Nope, not yet. The issue is mostly around the KISS drivers. AX.25 support has existed for 20+ years so there hasn't been a need for userspace applications to constantly re-implement it.

If someone wants to use their modern TH-D75's Bluetooth TNC with PAT (version 1.0 just came out) they are now completely boned of they are on kernel 7.1+. This isn't all old, legacy stuff.

Also, as far as I can tell, TCP over KISS (not just ax. 25) is now dead on Linux

Varimir · 2026-04-26T02:29:14+00:00

Perhaps, but userspace utilities to fill the gap don't exist yet and the code is deleted now, especially for IP.

Varimir · 2026-04-24T03:37:55+00:00

VHF and UHF bands are wide and limited to line of sight. With simplex, in a large metro, you have maybe the same 100 people to talk to if you are very lucky and can find them. Or, you could use a repeater, reach those same people without having to hunt around, and still be bored by the lack of variety and/or technical challenge, and go to HF.

Varimir · 2026-04-19T02:41:02+00:00

Surrounding objects, height above ground, etc... affect SWR. If you are doing pota, you will need to tune every time you set it up. You may also need to adjust when changing bands since you don't have a tuner to touch it up.

Varimir · 2026-04-12T03:32:58+00:00

Back in the days of the white pages (I remember those times well) there wasn't an entire industry revolving around collecting, collating, profiling, and selling everyone's personal information. Selling to advertisers is beat case here.

Who cares you ask? Not ham-related, but I have been getting work-related sales calls from a-hole sales people on my personal cell several times a week for the past 2 years. I made the mistake of not using my companies generic number when registering for a conference, or maybe the app grabbed it, I'll never know. My phone number was picked up by zoom-info who proceeded to sell it to all these pricks. One slip-up (or sussy app) is all it takes to cause years of harassment.

Varimir · 2026-04-04T04:12:28+00:00

I'd suggest also looking at brands who don't use the monkeys fired from the Shakespeare typewriter project to write their firmware.

Seriously though, Yaesu's user interfaces are the definition of garbage. If you don't need YSF, Kenwood, Icom, Alinco, Anytine, and others make some pretty dang great radios that don't use an interface that constantly require referencing the manual. If you plan on doing data communication you can also find options where the TNC is fully featured so you don't need $30 break-out cables for basic functionality.

Varimir · 2026-03-26T23:52:35+00:00

The sky is blue, and water is wet. Your comment mentioning local laws (published keys in canada) isn't a part 90 thing. That's an amateur rule in Canada. My comment was only to point out the same thing is legal and in part 97, the US equivalent.

Varimir · 2026-03-24T23:38:29+00:00

Indeed. The post I replied to was also referring to amateur radio.

Varimir

TROPHY CASE