Linux.Slashdot.org

Linux kernel maintainers "are grappling with how to integrate AI-generated contributions without compromising the project's integrity," reports WebProNews: The latest push comes from a proposal by Sasha Levin, a prominent kernel developer at NVIDIA, who has outlined guidelines for tool-generated submissions. Posted to the kernel mailing list, these guidelines aim to standardize how AI-assisted patches are handled. According to Phoronix, the v3 iteration of the proposal [posted by Intel engineer Dave Hansen] emphasizes transparency and accountability, requiring developers to disclose AI involvement in their contributions. This move reflects broader industry concerns about the quality and copyright implications of machine-generated code. Linus Torvalds, the creator of Linux, has weighed in on the debate, advocating for treating AI tools no differently than traditional coding aids. As reported by heise online, Torvalds sees no need for special copyright treatment for AI contributions, stating that they should be viewed as extensions of the developer's work. This perspective aligns with the kernel's pragmatic approach to innovation. The proposal, initially put forward by Levin in July 2025, includes a 'Co-developed-by' tag for AI-assisted patches, ensuring credit and traceability. OSTechNix details how tools like GitHub Copilot and Claude are specifically addressed, with configurations to guide their use in kernel development... ZDNET warns that without official policy, AI could 'creep' into the kernel and cause chaos... The New Stack provides insight into how AI is already assisting kernel maintainers with mundane tasks. According to The New Stack, large language models (LLMs) are being used like 'novice interns' for drudgery work, freeing up experienced developers for complex problems... The Linux kernel's approach could set precedents for other open-source projects. With AI integration accelerating, projects like those in the Linux Foundation are watching closely... Recent kernel releases, such as 6.17.7, include performance improvements that indirectly support AI applications, as noted in Linux Compatible.

Read more of this story at Slashdot.

Linux kernel developers are moving toward enabling Microsoft C Extensions (-fms-extensions) by default in Linux 6.19, with Linus Torvalds signaling no objection. While some dislike relying on Microsoft-style behavior, the patches in kbuild-next suggest the project is ready to "bite the bullet" and adopt the extensions system-wide. Phoronix reports: Rasmus Villemoes argued with Kbuild: enable -fms-extensions that would allow for "prettier code" and others have noted in the past the potential for saving stack space and all around being beneficial in being able to leverage the Microsoft C behavior: "Once in a while, it turns out that enabling -fms-extensions could allow some slightly prettier code. But every time it has come up, the code that had to be used instead has been deemed 'not too awful' and not worth introducing another compiler flag for. That's probably true for each individual case, but then it's somewhat of a chicken/egg situation. If we just 'bite the bullet' as Linus says and enable it once and for all, it is available whenever a use case turns up, and no individual case has to justify it..." The second patch is kbuild: Add '-fms-extensions' to areas with dedicated CFLAGS to ensure -fms-extensions is passed for the CPU architectures that rely on their own CFLAGS being set rather than the main KBUILD_CFLAGS. Linus Torvalds chimed in on the prior mailing list discussion and doesn't appear to be against enabling -fms-extensions beginning with the Linux 6.19 kernel.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: For years now, Valve has been slowly improving the capabilities of the Proton compatibility layer that lets thousands of Windows games work seamlessly on the Linux-based SteamOS. But Valve's Windows-to-Linux compatibility layer generally only extends back to games written for Direct3D 8, the proprietary Windows graphics API Microsoft released in late 2000. Now, a new open source project is seeking to extend Linux interoperability further back into PC gaming history. The d7vk project describes itself as "a Vulkan-based translation layer for Direct3D 7 [D3D7], which allows running 3D applications on Linux using Wine." The new project isn't the first attempt to get Direct3D 7 games running on Linux. Wine's own built-in WineD3D compatibility layer has supported D3D7 in some form or another for at least two decades now. But the new d7vk project instead branches off the existing dxvk compatibility layer, which is already used by Valve's Proton for SteamOS and which reportedly offers better performance than WineD3D on many games. D7vk project author WinterSnowfall writes that while they don't expect this new project to be upstreamed into the main dxvk in the future, the new version should have "the same level of per application/targeted configuration profiles and fixes that you're used to seeing in dxvk proper." And though d7vk might not perform universally better than the existing alternatives, WinterSnowfall writes that "having more options on the table is a good thing in my book at least." The report notes that the PC Gaming Wiki lists more than 400 games built on the aging D3D7 APIs, spanning mostly early-2000s releases but with a trickle of new titles still appearing through 2022. Notable classics include Escape from Monkey Island and Hitman: Codename 47.

Read more of this story at Slashdot.