While I know that it may have been a security liability, I'm particularly sad that they're removing the AX.25 module from the kernel.

> and since nobody stepped up to help us deal with the influx of the AI-generated bug reports we need to move it out of tree to protect our sanity.

This thread from the linux-hams mailing list [2] has more insight into this decision. I guess the silver lining is that, more modern protocols (in userspace), written in modern languages will become the norm for HAM radio on linux now.

[1] : <https://lwn.net/ml/all/20260421021824.1293976-1-kuba@kernel....>

[2] : <https://lore.kernel.org/linux-hams/CAEoi9W5su6bssb9hELQkfAs7...>

▲

ajross 3 hours ago | parent | next [-]

> more modern protocols (in userspace)

That's really it. The list of things that "need" to be in the kernel is shrinking steadily, and the downsides of having C code running in elevated privilege levels are increasing. None of that is about LLMs at all, except to the extent that it's a notable inflection point in a decades-scale curve.

The future, and we basically all agree, puts complexities like protocol handling and state in daemons and leaves only the hardware, process and I/O management in the kernel.

Basically, Tannenbaum was right about the design but wrong about the schedule and path to get there.

▲

anthk 2 hours ago | parent [-]

Except it's several times slower doing TCP/IP in userspace with programs than having a proper kernel for it, that's it, Hurd.

	▲	rwmj 2 hours ago \| parent \| next [-]
		I don't think this is actually true (eg. DPDK), but even if it is, you can put the driver in userspace (tun/tap + vfio/libusb/ioport/...) and still use TCP/IP in the kernel.
	▲	2 hours ago \| parent \| prev \| next [-]
		[deleted]
	▲	convolvatron 2 hours ago \| parent \| prev \| next [-]
		that's strictly not true. if I move the code that does TCP from the kernel into the application (not some other daemon, which is perhaps what you're suggesting), then the performance is to the first order the same. ok, what are the niggly details. we don't have interrupts, and we're running under the general scheduler, so there may be some effects from not getting scheduled as aggressively. we still need to coordinate through the kernel wrt port bindings, since those are global across the machine, but that's just a tiny bit. clearly we may be re-opening a door to syn-flooding, since the path to rejection is maybe longer. maybe not, but maybe we can leave the 3-way handshake in the kernel and put the datapath in userspace. we probably lose rtt-estimates hanging off of routes. none of that suggests 'several times slower'
	▲	varispeed 2 hours ago \| parent \| prev [-]
		But hardware manufacturers love it! Excuse to sell new faster machines.

▲

varispeed 2 hours ago | parent | prev [-]

Oh remember playing with that protocol ages ago. Sad.