this post was submitted on 10 Oct 2026
13 points (84.2% liked)

Linux

15173 readers
240 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
 

this should be a controversial post lol

top 3 comments
sorted by: hot top controversial new old
[–] avidamoeba@lemmy.ca 1 points 8 hours ago (2 children)

Using LLMs to backport approved paches in upstream software into older versions should be significantly easier and more accurate than producing the original patch and reviewing it. In the backport scenario the knowledge that the patch is "good" is already settled. The source around it is in place so the LLM has very tightly bounded context to work with, left with very little freedom to make mistakes. I think LLMs will make LTS releases significantly easier to maintain.

Debian btw.

[–] Die4Ever@retrolemmy.com 3 points 4 hours ago* (last edited 4 hours ago)

I wonder which way would give a better success rate.

  1. Write the patch for the latest LTS version and let the LLM forwardport it to master. (But don't roll out the LTS update until after the rolling distros get the patch?)
  2. Or write the patch for master and let the LLM backport it to LTS.

Especially if you're having the LLM port to every active LTS version, maybe option 1 would work since it's more like a midpoint? Kind of a more neutral zone, fewer commits to conflict in any direction. And that could theoretically prioritize the most recent LTS version as being the most reliable, which is probably what most critical deployments actually need.

[–] ProdigalFrog@slrpnk.net 8 points 6 hours ago* (last edited 6 hours ago)

Greg KH in a recent talk said even the most advanced LLM produces an incorrect result 50% of the time, I would not trust it to perform more reliably than a human even with tight boundaries.