Linux

15307 readers

285 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 3 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

Linux 7.4 Sound Changes Merged: "The AI Flood Continues" (www.phoronix.com)

submitted 1 day ago by cm0002@no.lastname.nz to c/linux@programming.dev

7 comments fedilink hide all child comments

Linux sound subsystem maintainer Takashi Iwai of SUSE began the Linux 7.4 sound pull request by noting that "the AI flood continues" with there continuing to be a lot of new patches coming as a result of AI/LLM agents devising patches as well as uncovering new kernel bugs.

Takashi went on to explain that it was another busy cycle with changes in the sound subsystem from lots of core code hardening to new platforms and codecs as well. The core ALSA code has been hardened against some race conditions, there's a buffer leak fix in the compression offload code, race fixes in the JACK code, and other race conditions and more typical C bug fixes. The OSS sequencer emulation code has also been marked as deprecated for Linux 7.4.

On the hardware side, the Linux 7.4 sound updates include support for compressed audio playback on SOF IPC4 with Intel Tigerlake and newer. There is also AMD ACP 7.0/7.F sound IP support with SoundWire and the PDM controller. The new AMD ACP 7.0/7.F IP appears for upcoming Ryzen Zen 6 platforms.

There are also quirks for many different Intel/AMD laptops from the likes of Lenovo, ASUS, HP, AAcer, HONOR, MSI, and others.

New codec drivers are for the ESS ES9039Q2M, Nuvoton NAU83G60 amplifier, Senary SN624x SoundWire SDCA codec.

Also new is the Qualcomm QAIF driver for their Shikra platform.

More details on the many sound changes for Linux 7.4 via this pull ( https://lore.kernel.org/lkml/87ecdgc246.wl-tiwai@suse.de/ ).

top 7 comments

sorted by: hot top controversial new old

[–] IntroSkeptic@lemmy.blahaj.zone 22 points 22 hours ago* (last edited 22 hours ago) (2 children)

Am I the only person that thinks fixing kernel bugs discovered with AI is a good thing? Like... AI is out there, we can't stop it now... People WILL use it, and using it to fix the bugs and even potential security vulnerabilities now, rather than letting a malicious actor do it sounds like something I'd very much like.

Even everyone saying Linus went full AI... Like... What? IMO he's being practical. It IS a tool, and there ARE a lot of things it should not be used for, but using it to patch things before human verification happens is a pretty sensible thing to do. Its no different than a crappy programmer submitting code for verification. It'd be a problem if there were too many PRs to handle, which has happened with some projects, but the kernel seems to be doing just fine?

The bigger issues with AI IMO are the environmental ones. But that's really a continuing trend from things like pushing computers around the world using Electron for no reason other than web developers being lazy and wanting to make an app without knowing anything but web dev. A whole-ass web browser is not needed for everything. Though I do admit AI has scaled this problem pretty astronomically...

Its also bad for creative endeavors. For the obvious reasons. I'm a game developer and I work with others who will sometimes try to code with AI and booooyyy do I give them an earful for that (its very noticeable, to those who think they're clever and can hide it. Just learn to fucking program ffs, its a lot faster than asking someone to program for you and having to constantly correct them because you don't understand wtf you're doing).

Would love to hear from someone who has been programming for a long time and isn't all just "AI bad because AI bad". Personally I've been around since 2014 or so.

[–] j3tt@lemmy.world 5 points 11 hours ago (1 children)

I agree with you, as long LLM users understand what they are doing.

That is why I do not vibe-code or vibe-admin. I only use it for research and ask follow-up questions if I don't understand what it just told me would work. I recently primed my LLM assistant to tell me where I can find more info so that I can verify. The goal for me is, learning things along the way and not produce unmaintainable code or configs.

[–] bigbangdangler@reddthat.com 1 points 16 minutes ago

I agree with you, as long LLM users understand what they are doing.

Just adding that this is the lesser-talked-about issue with AI adoption. While "it's a good tool" is a common argument, it really only holds true if the person using the tool is a skilled developer. For the moment, that's fine.

What happens in 10-20 years when there are no developers, because the younger folks only learned how to interact with the AI and not how to code from scratch? It seems to me that it ceases to become a good tool in the longer term. The issue is epistemological.

This kind of forward thinking is rarely applied for such cases, though. Capitalist ventures always focus exclusively on the short term, regardless of the lofty goals attached to them (which generally are only there to attract investment anyway, not to serve as any kind of deeper analysis of the potential effects of a product).

[–] towerful@programming.dev 5 points 22 hours ago (1 children)

There are issues with AI involving licensing and peoples IP and crediting sources and all that.

It has also massively reduced the barrier of entry for both finding and patching bugs, and producing realistic looking bug reports.
My biggest issue (other than enviromental and social impacts) is the load it puts on developers. They pretty much HAVE to use LLMs to triage and test bug reports... because it takes very little skill to use an LLM to "deep dive this area of the linux kernel and find a bug or RCE/CVE", and the LLM probably will. But the unskilled user might not understand what the exploit/bug actually is. But they get some sort of POC and some sort of write up, and then they dump it on someone elses plate.
If that bug is actually patched/impossible because of something outside of the scope/context that the LLM used, or if its only a bug because of bad config... yeh, its a bug, but it isnt an important one. And it eats up developer resources to confirm/triage/fix that bug.

Also, LLMs are an averaging engine. They work on "most likely" probability evaluations. So, you get average code.

There has to be a human in the loop

[–] IntroSkeptic@lemmy.blahaj.zone 2 points 19 hours ago

For a non-important piece of software, I agree that fixing small bugs is a waste of resources. This is this kernel.

I 100% agree there has to be a human in the loop. That's non-negotiable to me in ANY use of AI. I've personally been stuck reviewing AI code that sucks and have had to send back with a list of reasons... That fucking sucks too. I still appreciate things like finding bugs or users using AI and understanding what they're doing. It technically isn't AI that's the problem in a lot of cases... Its the misuse of a tool without understanding - which you get at. I don't like that sort of thing, but well... Its better than nothing happening IMO. As I mentioned in my original comment, the main problem is when its too much for maintainers. Then yeah. Outright ban it no matter the use-case. Software NEEDS to be engineered well or everyone is in for a rough time down the line.

[–] lnxtx@sopuli.xyz 9 points 1 day ago (1 children)

1 bug fixed, introducing 3 new bugs.

[–] MangoCats@feddit.it 3 points 20 hours ago

Business as usual. Have your LLM agent write a good regression test for that bug that was fixed so when a future change brings it back, at least you'll know before the merge.