Linux.Slashdot.org

BrianFagioli writes: Wine 11.0 has officially landed, wrapping up a year of development with more than 6,000 code changes and a broad set of upgrades that touch gaming, desktop behavior, and long-standing architectural work. The biggest milestone is the completion of the new WoW64 model, which is now considered fully supported and allows 32-bit and even 16-bit applications to run in a cleaner way inside 64-bit prefixes. Wine also gains support for the NTSYNC kernel module now bundled in Linux 6.14, which cuts overhead from thread synchronization and should deliver observable performance benefits in games and multi-threaded applications. A single unified wine binary now replaces the old wine64 launcher, and several system behaviors align more closely with modern Windows, including syscall numbering and NT reparse points. Graphics and desktop integration received more polish, including deeper Vulkan support (up to API 1.4.335), hardware-accelerated H.264 decoding through Direct3D, and further improvements to Wine's Wayland driver, which now supports clipboard operations, IMEs, and shaped windows. X11 users gain better window activation and fullscreen handling, and legacy DirectX features continue to expand under Wine's Vulkan renderer. Device support also moves forward, with better joystick handling, improved Bluetooth visibility and pairing, and working TWAIN scanning on 64-bit apps. Broad multimedia updates, DirectMusic refinements, .NET/XNA improvements, and developer-facing tools round out a release that appears focused on smoothing sharp edges rather than introducing flashy experiments. As always, source is live now and distro packages are rolling out.

Read more of this story at Slashdot.

Linus Torvalds has started experimenting with vibe coding, using Google's Antigravity AI to generate parts of a small hobby project called AudioNoise. "In doing so, he has become the highest-profile programmer yet to adopt this rapidly spreading, and often mocked, AI-driven programming," writes ZDNet's Steven Vaughan-Nichols. Fro the report: [I]t's a trivial program called AudioNoise -- a recent side project focused on digital audio effects and signal processing. He started it after building physical guitar pedals, GuitarPedal, to learn about audio circuits. He now gives them as gifts to kernel developers and, recently, to Bill Gates. While Torvalds hand-coded the C components, he turned to Antigravity for a Python-based audio sample visualizer. He openly acknowledges that he leans on online snippets when working in languages he knows less well. Who doesn't? [...] In the project's README file, Torvalds wrote that "the Python visualizer tool has been basically written by vibe-coding," describing how he "cut out the middle-man -- me -- and just used Google Antigravity to do the audio sample visualiser." The remark underlines that the AI-generated code met his expectations well enough that he did not feel the need to manually re-implement it. Further reading: Linus Torvalds Says Vibe Coding is Fine For Getting Started, 'Horrible Idea' For Maintenance

Read more of this story at Slashdot.

A year ago the Steam Survey showed a 2.29% marketshare for Linux. Last May it reached 2.69%, its highest level since 2018. November saw another all-time high of 3.2%. But December brought a surprise, reports Phoronix: Back on the 1st Valve published the Steam Survey results for December 2025 and they put the Linux gaming marketshare at 3.19%, a 0.01% dip from November. But now the December results have been revised... [and] put the Linux marketshare at 3.58%, a 0.38% increase over November. Valve didn't publish any explanation for the revision but occasionally they do put out monthly revised data. This is easily an all-time high... both in percentage terms and surely in absolute terms too.

Read more of this story at Slashdot.

An anonymous reader shared this report from It's FOSS: Jenny Guanni Qu, a researcher at [VC fund] Pebblebed, analyzed 125,183 bugs from 20 years of Linux kernel development history (on Git). The findings show that the average bug takes 2.1 years to find. [Though the median is 0.7 years, with the average possibly skewed by "outliers" discovered after years of hiding.] The longest-lived bug, a buffer overflow in networking code, went unnoticed for 20.7 years! [But 86.5% of bugs are found within five years.] The research was carried out by relying on the Fixes: tag that is used in kernel development. Basically, when a commit fixes a bug, it includes a tag pointing to the commit that introduced the bug. Jenny wrote a tool that extracted these tags from the kernel's git history going back to 2005. The tool finds all fixing commits, extracts the referenced commit hash, pulls dates from both commits, and calculates the time frame. As for the dataset, it includes over 125k records from Linux 6.19-rc3, covering bugs from April 2005 to January 2026. Out of these, 119,449 were unique fixing commits from 9,159 different authors, and only 158 bugs had CVE IDs assigned. It took six hours to assemble the dataset, according to the blog post, which concludes that the percentage of bugs found within one year has improved dramatically, from 0% in 2010 to 69% by 2022. The blog post says this can likely be attributed to: The Syzkaller fuzzer (released in 2015) Dynamic memory error detectors like KASAN, KMSAN, KCSAN sanitizers Better static analysis More contributors reviewing code But "We're simultaneously catching new bugs faster AND slowly working through ~5,400 ancient bugs that have been hiding for over 5 years." They've also developed an AI model called VulnBERT that predicts whether a commit introduces a vulnerability, claiming that of all actual bug-introducing commits, it catches 92.2%. "The goal isn't to replace human reviewers but to point them at the 10% of commits most likely to be problematic, so they can focus attention where it matters..."

Read more of this story at Slashdot.

Gentoo Linux posted its 2025 project retrospective this week. Some interesting details: Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg. Codeberg is a site based on Forgejo, maintained by a non-profit organization, and located in Berlin, Germany. Gentoo continues to host its own primary git, bugs, etc infrastructure and has no plans to change that... We now publish weekly Gentoo images for Windows Subsystem for Linux (WSL), based on the amd64 stages, see our mirrors. While these images are not present in the Microsoft store yet, that's something we intend to fix soon... Given the unfortunate fracturing of the GnuPG / OpenPGP / LibrePGP ecosystem due to competing standards, we now provide an alternatives mechanism to choose the system gpg provider and ease compatibility testing... We have added a bootstrap path for Rust from C++ using Mutabah's Rust compiler mrustc, which alleviates the need for pre-built binaries and makes it significantly easier to support more configurations. Similarly, Ada and D support in gcc now have clean bootstrap paths, which makes enabling these in the compiler as easy as switching the useflags on gcc and running emerge. Other interesting statistics for the year: Gentoo currently consists of 31,663 ebuilds for 19,174 different packages.For amd64 (x86-64), there are 89 GBytes of binary packages available on the mirrors.Gentoo each week builds 154 distinct installation stages for different processor architectures and system configurations, with an overwhelming part of these fully up-to-date.The number of commits to the main ::gentoo repository has remained at an overall high level in 2025, with a slight decrease from 123,942 to 112,927.The number of commits by external contributors was 9,396, now across 377 unique external authors. Thanks to long-time Slashdot reader Heraklit for sharing the 2025 retrospective.

Read more of this story at Slashdot.

Is there a trend? This week four different articles appeared on various tech-news sites with an author bragging about switching to Linux. "Greetings from the year of Linux on my desktop," quipped the Verge's senior reviews editor, who finally "got fed up and said screw it, I'm installing Linux." They switched to CachyOS — just like this writer for the videogame magazine Escapist: I've had a fantastic time gaming on Linux. Valve's Windows-to-Linux translation layer, Proton, and even CachyOS' bundled fork have been working just fine. Of course, it's not perfect, and there's been a couple of instances where I've had to problem-solve something, but most of the time, any issues gaming on Linux have been fixed by swapping to another version of Proton. If you're deep in online games like Fortnite, Call of Duty, Destiny 2, GTAV or Battlefield 6, it might not be the best option to switch. These games feature anti-cheats that look for versions of Windows or even the heart of the OS, the kernel, to verify the system isn't going to mess up someone's game.... CachyOS is thankfully pre-packed with Nvidia drivers, meaning I didn't have to dance around trying to find them.... Certain titles will perform worse than their counterparts, simply due to how the bods at Nvidia are handling the drivers for Linux. This said, I'm still not complaining when I'm pushing nearly 144fps or more in newer games. The performance hit is there, but it's nowhere near enough to stave off even an attempt to mess about with Linux. Do you know how bizarre it is to say it's "nice to have a taskbar again"? I use macOS daily for a lot of my work, which uses a design baked back in the 1990s through NeXT. Seeing just a normal taskbar that doesn't try to advertise to me or crash because an update killed it for some reason is fantastic. That's how bad it is out there right now for Windows. "I run Artix, by the way," joked a senior tech writer at Notebookcheck (adding "There. That's out of the way...") I dual-booted a Linux partition for a few weeks. After a Windows update (that I didn't choose to do) wiped that partition and, consequently, the Linux installation, I decided to go whole-hog: I deleted Windows 11 and used the entire drive for Linux... Artix differs from Arch in that it does not use SystemD as its init system. I won't go down the rabbit hole of init systems here, but suffice it to say that Artix boots lightning quick (less than 10 seconds from a cold power on) and is pretty light on system resources. However, it didn't come "fully assembled..." The biggest problem I ran into after installing Artix on the [MacBook] Air was the lack of wireless drivers, which meant that WiFi did not work out of the box. The resolution was simple: I needed to download the appropriate WiFi drivers (Broadcom drivers, to be exact) from Artix's main repository. This is a straightforward process handled by a single command in the Terminal, but it requires an internet connection... which my laptop did not have. Ultimately, I connected a USB-to-Ethernet adapter, plugged the laptop directly into my router, and installed the WiFi drivers that way. The whole process took about 10 minutes, but it was annoying nonetheless. For the record, my desktop (an AMD Ryzen 7 6800H-based system) worked flawlessly out-of-the-box, even with my second monitor's uncommon resolution (1680x1050, vertical orientation). I did run into issues with installing some packages on both machines. Trying to install the KDE desktop environment (essentially a different GUI for the main OS) resulted in strange artifacts that put white text on white backgrounds in the menus, and every resolution I tried failed to correct this bug. After reverting to XFCE4 (the default desktop environment for my Artix install), the WiFi signal indicator in the taskbar disappeared. This led to me having to uninstall a network manager installed by KDE and re-linking the default network manager to the runit services startup folder. If that sentence sounds confusing, the process was much more so. It has been resolved, and I have a WiFi indicator that lets me select wireless networks again, but only after about 45 minutes of reading manuals and forum posts. Other issues are inherent to Linux. Not all games on Steam that are deemed Linux compatible actually are. Civilization III Complete is a good example: launching the game results in the map turning completely black. (Running the game through an application called Lutris resolved this issue.) Not all the software I used on Windows is available in Linux, such as Greenshot for screenshots or uMark for watermarking photos in bulk. There are alternatives to these, but they don't have the same features or require me to relearn workflows... Linux is not a "one and done" silver bullet to solve all your computer issues. It is like any other operating system in that it will require users to learn its methods and quirks. Admittedly, it does require a little bit more technical knowledge to dive into the nitty-gritty of the OS and fully unlock its potential, but many distributions (such as Mint) are ready to go out of the box and may never require someone to open a command line... [T]he issues I ran into on Linux were, for the most part, my fault. On Windows or macOS, most problems I run into are caused by a restriction or bug in the OS. Linux gives me the freedom to break my machine and fix it again, teaching me along the way. With Microsoft's refusal (either from pride or ignorance) to improve (or at least not crapify) Windows 11 despite loud user outrage, switching to Linux is becoming a popular option. It's one you should consider doing, and if you've been thinking about it for any length of time, it's time to dive in. And tinkerer Kevin Wammer switched from MacOS to Linux, saying "Linux has come a long way" after more than 30 years — but "Windows still sucks..."

Read more of this story at Slashdot.

Linus Torvalds has weighed in on an ongoing debate within the Linux kernel development community about whether documentation should explicitly address AI-generated code contributions, and his position is characteristically blunt: stop making it an issue. The Linux creator was responding to Oracle-affiliated kernel developer Lorenzo Stoakes, who had argued that treating LLMs as "just another tool" ignores the threat they pose to kernel quality. "Thinking LLMs are 'just another tool' is to say effectively that the kernel is immune from this," Stoakes wrote. Torvalds disagreed sharply. "There is zero point in talking about AI slop," he wrote. "Because the AI slop people aren't going to document their patches as such." He called such discussions "pointless posturing" and said that kernel documentation is "for good actors." The exchange comes as a team led by Intel's Dave Hansen works on guidelines for tool-generated contributions. Stoakes had pushed for language letting maintainers reject suspected AI slop outright, arguing the current draft "tries very hard to say 'NOP.'" Torvalds made clear he doesn't want kernel documentation to become a political statement on AI. "I strongly want this to be that 'just a tool' statement," he wrote.

Read more of this story at Slashdot.