all 27 comments

sorted by: hot top controversial new old
[–] 62 points 1 day ago* (last edited 1 day ago) (9 children)

Is this the one where the LLM generated code introduced some severe bug (memory leak or buffer overflow or something), then Linus went on vacation and another dude cleaned it up?

https://lkml.iu.edu/2610.1/13698.html afaik

If yes, then it annoys me that the articles on this are so biased. Because it actually shows the middle ground reality of using LLMs in development instead of the utopia/dystopia extreme views we keep seing online.

  • source
  • hideshow 9 child comments
  • [–] 13 points 1 day ago

    went on vacation and another dude cleaned it up

    the utopia/dystopia extreme views we keep seing

    It's almost like the person going on vacation comes away with a positive view, and the person cleaning up after them comes away with a negative view . . .

  • source
  • parent
  • [–] [S] 2 points 1 day ago (6 children)
  • [–] 5 points 1 day ago (5 children)
  • [–] [S] 4 points 1 day ago* (4 children)

    Did AI generate that race condition commit of linus?

  • source
  • parent
  • hideshow 4 child comments
  • [–] 18 points 1 day ago* (2 children)

    (sorry, I thought by "that" you meant my comment or the content of the link or something else)

    As far as I understand, Linus did an LLM assisted coding session that resulted in code with a race condition. But to what extend he or the LLM is specifically responsibe for the bug, we don't know because he didn't share the session, only the result.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 17 points 1 day ago

    Yes we get it, he drank the Kool-AId...

  • source
  • [–] 15 points 1 day ago (3 children)

    Shit site keeps kicking me out for my ad-blocker

  • source
  • hideshow 3 child comments
  • [–] 28 points 1 day ago (2 children)

    Full articleAfter a few revisions of his position on AI-assisted contributions to the Linux kernel, Linus Torvalds has posted his own first LLM-assisted patch. The development branch purports to fix an old issue with massive cache contention when many CPUs are reading the same file — a scenario potentially encountered when using shared libraries, databases, and web servers. Several developers had already made attempts over the years at fixing the issue, all with varied results, none quite ideal as an all-encompassing solution.

    Torvalds posted his own draft for solving the problem in early 2024, and has used it on his own laptop since that time. However, he recently took the plunge and decided to "try to actually solve this thing using an LLM." He's now posted his solution in a development branch, and claims that he's seen a 23x performance improvement in a dedicated synthetic benchmark, though he notes that actual real-world impact will be far less significant, as "no real load" will witness those figures. If we had to guess, this improvement would benefit server workloads far more than desktop machines.

    Over time, Torvalds has broadly taken a pro-AI stance on LLM tooling, at least within the purview of the tightly controlled, review-heavy environment of the Linux kernel code. Last July, he stated he's "willing to absolutely put [his] foot down" on AI haters, pointing out that an automated code review tool the kernel team uses outperforms humans, and that it caught basic programming mistakes that shouldn't have been submitted in the first place.

    The team is even changing its policy to no longer require that patch authors disclose they used an AI tool when generating their code. Torvalds once again took an assertive stance, reiterating that users should treat LLMs as yet another tool, likening it to compilers or editors. In his view, he simply expects that "people do their best and [...] understand what they are doing."

    Some might say that few people in the world are better-suited to properly employ an LLM than Torvalds, and by extension, kernel maintainers. There's an entire universe of difference between a senior master programmer using the LLM to speed up the boring parts of his work, and some newbie with a credit card going "claude make linux faster plz no mistakes."

    However, It's not all roses. Thanks to how adept AI agents have become at recognizing common security flaw patterns, the Linux security mailing list became "unmanageable" earlier in the year. Linux has been fixing CVEs at an astonishingly rapid pace of around 2,000 per release. Still, the team's hand is being forced into dropping older hardware drivers, as they're often the target of numerous security reports, despite their negligible install base.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 3 points 1 day ago (3 children)

    Man, this is going to garner a lot of hate by people who hate AI just by virtue of it being AI.

  • source
  • hideshow 3 child comments
  • [–] 4 points 1 day ago* (last edited 1 day ago)

    Welcome to Lemmy, where the hive mind has decided progress is bad, and will criticize anyone who disagrees until they either shut up or become one with the hive mind. People who still speak their own disagreement are the minority, and are rewarded with copious downvotes. They've made up their mind, and discourse is heavily discouraged.

  • source
  • parent
  • [–] 3 points 1 day ago (7 children)

    then distros need to start rejecting any linus contributed code and fork the kernel.

  • source
  • hideshow 7 child comments
  • [–] [S] 17 points 1 day ago (1 child)

    Just what the Linux community needs, more fragmentation

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 17 hours ago

    Open source when someone forks something for a reason that aligns with my worldview: "The beauty of open source! Anyone can fix a problem!"

    Open source when someone forks something for a reason that doesn't align with my worldview:

  • source
  • parent
  • [–] 3 points 1 day ago

    A fork would need lots of initiative from existing kernel developers. Distro people are more of userspace integrators, less system programmers. I think distros will experiment with rebasing against different kernels, maybe a revival of Debian GNU/kFreeBSD or something. At the end of the day though, it's up to laptop and phone manufacturers whether to put money into developing hardware support on top of those.

  • source
  • parent