[–] 2 points 3 weeks ago

I feel like I had posted screen shots through it a couple times. This was about 2-3 years ago and I may be misremembering. If you can't do that via web, then I'd not expect it to work unless I was using a Teams for Linux that wasn't a web wrapper, but I thought they all were web wrappers on Linux.

  • source
  • parent
  • context
  • [–] 19 points 3 weeks ago*

    (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
  • context
  • [–] 65 points 3 weeks ago* (last edited 3 weeks ago) (4 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
  • [–] 24 points 3 weeks 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
  • context
  • [–] 1 point 3 weeks ago

    Bazzite has been nothing but a pain in my ass since I put together a build for my wife to play games on. Controller drop out on Bluetooth. Then the next update broke Bluetooth on the entire system. Issues with video output after wake from sleep. The absolute mess that is trying to setup sunshine and get it to work in game mode.

    At this point if one more thing happens I'm seriously dumping the entire thing and moving it over to a real distro so I don't have to ever deal with an immutable os ever again.

  • source
  • [–] 3 points 3 weeks ago

    The MUST contribute back.

    If they go into this as "yay, we get software for free" they are bound to fail and are leeching the community. They should contribute the same or at least half of what they're spending on proprietarysoftware currently.

  • source
  • [–] 2 points 3 weeks ago (1 child)

    It's a slop bridge to play your slop games through the slop service on a different slop OS than the original slop OS that the slop service is actually made for.

  • source
  • parent
  • context
  • [–] 1 point 3 weeks ago

    I like Bazzite because when I get into some kind of hyperfocus rabbit hole with some kind of tool/language/library/project, it basically forces me to make a Distrobox for it instead of making a mess in my system, and I can easily clean up all of the random packages and dependencies once I get border with it and inevitably start running out of disk space.

  • source
  • [–] 2 points 3 weeks ago (1 child)

    I dont know if I'd call them forks, they're more like unmerged branches.

    Like the bulds with different schedulers, the only thing different about them is they include an extra module that's not included by upstream, everything else is a 1:1 match for upstream, and follows closely.

    I'd personally say the real-time kernel would come close to it, but even that was still roughly tracking upstream, and was merged in the end.

  • source
  • parent
  • context
  • view more: ‹ prev next ›