IBM and Red Hat say their AI-powered Lightwell initiative has identified and helped remediate more than 400 previously unknown vulnerabilities across widely used Java libraries. Phoronix reports: They announced this feat today as part of their promoting Lightwell Clearinghouse to GA, which is an enterprise service for their customers to submit open-source software dependencies for priority review and remediation.

From today's announcement: "The milestone addresses a growing business risk. As autonomous AI agents become capable of combining several lower-risk software weaknesses into a more serious attack, companies need to do more than identify vulnerabilities. They need a practical way to develop, test and deploy fixes in the software that supports critical applications."

Phoronix reports: Steam on Linux use in March hit an all-time high of around 5.33% marketshare. Since then it pulled back to around 4% while for September 2026 the Steam Survey results... indicate a rather steep decline of 0.85%, down to 3.05%. Meanwhile macOS is at 1.92% and Microsoft Windows at 95%... Steam's Survey reports a 7.42% increase in Chinese use, up to 31.39% overall of the Steam population. Usually those large month-over-month swings where Steam China use shoots up dramatically is a boost to Windows and a detriment to Linux. Some attribute the large increases in Simplified Chinese use to being a reporting/sampling issue.

When diving into the Steam Linux data exclusively, CachyOS has spiked by another 2.65% to now account for 18.12% of the sampled Linux gaming population. That even outperforms SteamOS Holo coming in at 17.37%. Among Linux gamers on Steam, AMD CPUs still account for the high 60 percentage space thanks to the Steam Deck and Steam Machine using AMD APUs and their open-source/Linux support being popular with enthusiasts.

BrianFagioli shares a report from NERDS.xyz: Microsoft has made WSL Containers generally available, giving Windows 11 developers a built-in way to build, run, and deploy Linux containers through Windows Subsystem for Linux. The release includes wslc.exe for managing containers, GPU support, networking improvements, health checks, storage mounts, and integration with Microsoft Defender for Endpoint and Intune. Microsoft also claims up to twice the performance when Linux environments access files stored on Windows.

Docker Desktop, Podman Desktop, and Rancher Desktop are not going anywhere, but developers who only need basic container functionality now have another option built around WSL. One notable feature is still missing: Compose support. Microsoft says adding it is now a priority.

"Finding vulnerabilities faster also puts pressure on Linux distributions to fix and deliver patches faster," writes Slashdot reader BrianFagioli

AI has transformed bug discovery from "a manual, time-intensive process into a highly automated engine," notes Canonical's blog, leading to a "recent explosion in the volume of CVEs". Additionally, the upstream kernel community became its own CVE Numbering Authority (CNA) and assigned CVE (Common Vulnerabilities and Exposures) identifiers to thousands of bugs, arguing that at the kernel level, almost any type of bug that can affect a running system, could potentially be classified as a vulnerability. As a result, the volume of CVEs has skyrocketed exponentially, creating a massive backlog of alerts and forcing defenders to drastically increase the speed of their fixes to close the window of risk.

To address the growing volume of CVEs and the demand for faster security fixes, we are transitioning to a unified, 2-week release cycle...

While a patch is being prepared, Canonical aims to provide safe workarounds where applicable, so users aren't left exposed in the meantime. Where no safe workaround exists, Canonical will say so clearly and point users toward general hardening steps instead. The goal is to get environments into a defensible, safer state within 24 to 48 hours of public disclosure — well before a patch ships. This doesn't replace the patch; it buys the time needed to fix the vulnerability properly, without sacrificing security.
"Linux did not suddenly become wildly insecure overnight," notes the blog Nerds.xyz. "We are getting much better at finding and cataloging problems that may have previously gone unnoticed." There is something almost ironic about all of this. AI is routinely pitched as a tool that will make software development faster, but it is also making vulnerability discovery faster. That means maintainers now have to accelerate the other side of the equation too.

For Ubuntu users, that should ultimately be good news. More bugs being discovered is preferable to vulnerabilities sitting unnoticed in the Linux kernel.

Snapdragon X2 Series processors feature a neural processing unit (NPU) delivering 80 trillion operations per second and allowing advanced AI features to run locally. And Snapdragon X2 Series "is expanding to Linux," Qualcomm announced today, calling it one of their most-requested capabilities: Qualcomm Technologies is a top contributor to Linux development at a kernel level, and now we're embracing support for Snapdragon X2 Series as a platform directly. We're upstreaming core drivers for Snapdragon X2 Series — including the Hexagon NPU and Adreno GPU — to open the door to developers and partners. We are starting with support for two operating systems based on Linux...

- Debian: We're kicking off with Debian by the end of this year, one of the most influential Linux distributions and the foundation behind many of the distros people use every day.
- Ubuntu: Qualcomm Technologies has partnered with Canonical to bring Ubuntu, the world's most widely used Linux distro, to the platform with Snapdragon X2 Series certification targeted for the first half of 2027.

...and this is just the beginning. Our partners HP, ASUS and HUMAIN are planning Linux support in the first of 2027, so that their devices deliver the incredible experience users expect with Snapdragon X2 Series in a new operating system.
Qualcomm's developer blog called it "a significant step forward" in Qualcomm's commitment to a developer-first approach, and "to the open-source community."

"For developers, the important part is simple: more core hardware features are being reviewed and merged, so that laptops with Linux on Snapdragon X2 Series will be easier to build, test, and debug..." The enablement work completed so far has been validated on a Debian 13-based ("Trixie") user space and a custom kernel, so developers should treat this as the current reference environment while support continues to mature... Linux support for laptops with Snapdragon X2 Series is rolling out in stages, starting with the core pieces developers need before they can do production-level work on their device... For developers who want to try it today, the call to action is straightforward: start with Snapdragon X2 Series hardware, review the latest recipes to build Qualcomm Linux Debian Images, build available upstream sources the Debian OS image and test the peripherals that matter to you, such as graphics, AI inference, device I/O, or basic application bring-up. Early testing helps identify the gaps that matter most before support becomes broader and ready for production-level workloads...

You do not have to wait for everything to be fully finished before getting hands-on. If you are comfortable working from upstream sources you can start evaluating Snapdragon X2 hardware today... Check out the step-by-step instructions, including the full build flow and deployment guidance for Snapdragon X2 Series Linux software.

Put simply, this effort is less about supporting specific Linux distributions and more about empowering the developers who make Linux available on new hardware. This Developer Preview targets distribution maintainers, toolchain developers, kernel contributors, and hardware enablement engineers. It provides the upstream building blocks, including kernel patches, drivers, and reference device trees, needed to enable Snapdragon X2 Series support in their own projects and distributions. For end users looking for a turnkey "install and go" experience, that will come later as distributions adopt what lands upstream. We're encouraging the community to build on this work and help shape what comes next.
The blog post notes that in the initial enablement stage, "Qualcomm Linux supports systemd-boot as the Universal extensible firmware interface (UEFI) boot manager to load and boot the Linux kernel."

Hands-on demos were given at the Snapdragon Summit in Maui of Linux running on Snapdragon X2 Series hardware, which the developer's blog calls "a practical look at what works today and where Snapdragon X2 Series Linux support is headed."

"In April this year, we saw Andy Nguyen turning the PS5 into a Linux-powered gaming PC," writes the blog It's FOSS.

It ran Steam games and emulators using the PS5's on-board hardware. But this week Andy announced he's "stopping all my work on PS5 Linux" and "stepping away from the PS5 scene." stopping work on porting the project to the PS5 Pro, which would've shipped sometime in 2027. Andy Nguyen: After pouring my heart and months of my life into it, including plans to finish PS5 Pro support and release in 2027, it's all down the sink.

The scene used to be a group of highly talented researchers, but now it is just a bunch of noobs using LLMs and writing hacks they don't even understand. Slop kiddies found the only hypervisor bug left, which I had also found a while ago, and decided to report to Sony. I asked them to at least wait for GTA 6 to come out so that people would have the opportunity to legally purchase the game and also enjoy Linux. They agreed to wait, but not a day passed and they decided to waste it instead.
Or, as It's FOSS tells it: Running Linux on a PlayStation console is possible because the PS5 Linux project was able to find a way past the hypervisor using exploits Sony had already patched, covering firmware 3.00 through 7.61. ..

[The bug's discoverer writes it was] found with what he calls his "trusty ai clanker machine" and no help from anyone else. He had even agreed to Andy's request to not disclose the findings. Unexpectedly, a third person, still unnamed, found the same bug using AI a few hours later. Anticipating that there would be more people finding the same bug, [he] decided to post the flaw on HackerOne.

The project's GitHub page and all the related repositories are still there. Nothing has been archived as of today, and if you wanted to, you could start contributing to the PS5 Linux project by taking over any pending work or cooking up new improvements... The PS5 Pro support Andy was building never reached the repository, so you would have to start from scratch... While Andy's departure is a blow to the plan for supporting newer PS5 firmware and the PS5 Pro, other contributors have shown that they can deliver work on the loader without him, and I am hopeful more will follow.

Longtime Slashdot reader Microsplat: CERN plans to have all 2,200+ industrial computers and embedded systems in its accelerator-control infrastructure running Debian 13 by the end of 2026. These are systems used for accelerator control, laboratory equipment and other operational functions ... They also generate and interact with a hefty amount of data, although this Linux.com article refers more broadly to CERN's computing infrastructure. It's unclear whether the Debian migration covers all server infrastructure or what scientific-research-based systems are included. Our shops have done much the same in recent years, mostly due to CentOS and CFEngine getting the can. Phoronix adds some additional context in its article: CERN was a longtime RHEL/CentOS shop, previously co-maintained the Scientific Linux RHEL derivative, moved to CentOS in 2015, and later considered CentOS Stream. CERN says Red Hat's adoption of the "-march=x86-64-v2" compiler flag by default, which it viewed as "forced obsolescence" of older hardware, was the "straw that broke the camel's back."

"Multikernel Technologies has put out mklinux v7.0-mk2, the first public release of the multikernel Linux tree it's been building since last year," reports the blog It's FOSS: The basic premise of the project is that one physical server can run several independent Linux kernels side by side, each with its own dedicated CPUs and memory. So, the same box could run a database on one kernel and a GPU training job on another without either kernel touching the other's resources... One kernel runs as the host, controlling the machine's CPUs, memory, and PCI devices. When it spins up a new kernel instance, that instance gets its own dedicated slice of hardware and boots straight onto it using Linux's kexec mechanism, running natively rather than under a hypervisor.

The host tracks all of this through device tree overlays under /sys/fs/multikernel/, and it can shift hardware between running instances while everything stays up.

That's a different setup from both VMs and containers. A VM still puts a hypervisor and a host kernel between the app and the hardware. A container skips the hypervisor, but every tenant on the machine shares one kernel... This release only supports x86_64 hardware, though Multikernel Technologies says the architecture-specific code is already modular enough for other ports to follow later.
The article notes they're selling multiple products based on the kernel tree, including one for running AI agents in their own kernel with direct GPU access and one that promises to patch a running kernel without taking the system down.

The Linux Foundation's director of IT infrastructure says they now spend more CPU cycles "rendering commits for scrapers than we spend on all other kinds of legitimate access." At any one time, across 5 geo-distributed nodes, there are 14 CPU cores doing nothing but rendering git commits as html....

[W]hen a source is guaranteed to be LLM-free, like the entire history of kernel commits, it's worth its weight in gold as a source of training data... At the time of writing, linux.git is about 1.48 million commits. Oh, and we have about 922 forks of it on git.kernel.org — but don't worry, it's actually extremely efficient on the backend, since it's mostly the same objects in every fork. Unless, of course, you're a scraper, in which case you have, oh, several BILLION valid URLs you can scrape, only to get 922 duplicates of the same 1.48 million commits — which is exactly what the scrapers are doing. But wait, it's not just commits itself. You can also ask for patches, plain renders, diffs between arbitrary commits — cgit is happy to let you, which was perfect for the times when the Internet was for humans or crawlers who obeyed robots.txt, and is AWFUL right about now, because we can generate 1.2 METRIC BAJILLION valid URLs just for a single fork of linux.git.

Initially, this was the solution — look through the logs, find out which IPs are obvious scraper bots, and fail2ban them. At first, this was easy, because the bots helpfully told you who they were via their user-agent. Then, they wised up and started pretending that they were random vanilla browsers. So, we started banning them by IP — after all, it's easy to figure out that an IP that is trying to grab every possible commit in a 8-year-old abandoned fork of linux is not really some lone Chrome on Windows user who is just furiously clicking every link that comes across their screen. The bots then started fanning out to entire subnets, but this was still meh, because obviously an IP coming from Google Compute is just pretending to be a Firefox user...

And... that's when things turned really, really ugly. Suddenly, the crawlers were coming from millions of random residential or mobile IPs, all pretending to be random modern browsers. An IP like that would make 4-5 requests and then never show up in the logs again... They descended like swarms of locust, hit hard and fast until the system fell over and then moved on to the next target until you recovered. Then, they returned. Rinse. Repeat. They still do that — welcome to the wonderful world of "proxy SDK monetization." It's big business, and your TV is probably doing it...

Today, git.kernel.org receives about 6M daily requests demanding to see random commits. Of these, 66% are still immediately batted away with the Anubis challenge, but 33% are now solving the math and getting through to the main site — because apparently what we have to offer is worth spending a ton of cycles to calculate the Anubis challenge... With a bunch of generous assumptions, legitimate requests are only about 2% of git.kernel.org traffic — everything else are scrapers...

[W]e're turning off features to reduce the number of crawlable URLs and to gate off actions that are expensive for us to run. Expect to lose some functionality, at least when accessing our resources anonymously. Trust me, we hate it just as much as you, but at this point it's a necessity... [W]e promise to still offer all of our data for download to anyone who asks. You just may have to jump through more hoops to get it.

Sorry.

Citrix's Desktop as a Service (DaaS) product includes a lightweight, hardened second operating system called UniconOS (once called "eLux") to offer Windows customers a write-protected file system Citrix says is secure against computer viruses and other malware. Nerds.xyz reports: According to the company, the environment remains isolated from the Windows filesystem and uses Secure Boot protections covering the shim, bootloader, kernel, and initial RAM filesystem. That separation matters when ransomware encrypts Windows or a faulty update leaves the operating system trapped in a boot loop. Instead of repairing Windows immediately, an employee can boot into UniconOS and use Citrix DaaS to access virtual applications and desktops.

Citrix SecurAccess with Chrome Enterprise provides access to internal web applications under the organization's existing security policies. In other words, UniconOS does not actually fix the damaged Windows installation. It gives employees another route to their applications while the IT department investigates or repairs Windows... [T]he installer shrinks the Windows volume, creates a new partition, copies UniconOS onto it, and registers the necessary boot entries. Windows remains the default operating system during ordinary use, although administrators can configure boot delays and fallback behavior...

The approach could prove useful following a widespread ransomware attack or another defective Windows update resembling the CrowdStrike incident of 2024. Recovery would happen independently on every compatible endpoint instead of requiring IT employees to physically handle thousands of computers.
Thanks to Slashdot reader BrianFagioli for sharing the news.

This week Debian voted on whether to ban AI-assisted contributions. The winning proposal? "Debian neither endorses nor prohibits the use of generative AI tools" in its projects, documentation, and packaging... Generative AI "is neither exempt from nor subject to special rules beyond the standards already expected of Debian contributors."

"The responsibility for every contribution rests with the contributor who submits it, who remains accountable for its technical quality, legal acceptability, and suitability for inclusion in Debian." "We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.

The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian. Blindly accepting or uploading AI-generated material without appropriate human review is inconsistent with Debian's established development practices.

We enourage our contributors to disclose whether a contribution was made with AI assitance, but do not require them to do so.

Debian acknowledges that the legal status of material produced by generative AI systems remains the subject of ongoing discussion in many jurisdictions, including questions relating to copyright... The Project does not seek to resolve these unsettled legal questions through this General Resolution, nor does it adopt a position on whether AI-generated output is, in whole or in part, copyrightable or derived from copyrighted works. Instead, Debian continues to rely on the judgment and responsibility of its individual contributors. Project members are expected to exercise appropriate care when using generative AI tools, to consider the provenance and licensing implications of material they contribute, and to avoid introducing content whose legal status they cannot reasonably justify. Existing Debian policies governing licensing, copyright, software freedom, and the acceptance of contributions continue to apply irrespective of the tools used to produce those contributions.
It also cautions contributors to keep keys, credentials, and embargoed security reports from leaking to third-party AI services.

But discussion continues on Debian's mailing list. "I regret the loss of contributors," wrote the author of the winning proposition (while acknowledging it would have happened with either option winning). "It is just too early to take a final decision on the matter. Let's revisit this in two years or so, and let this mess of a GR be a warning for our future selves."

Other comments from the mailing list:

• "On a very personal note, I regret that the winning option does not acknowledge all the legitimate concerns around AI: environmental impact, copyright and licensing uncertainty, the health of Free Software communities, and the strain of aggressive scraping on the open web... [W]e have a lot of work ahead of us to act as a community and understand how we can continue to accommodate the very large minority that would have preferred to ban or discourage AI.

• "I also think that our next discussion should distinguish between locally running LLMs and cloud LLMs. The way things are going, locally running LLMs will be an alternative, and then you can much better control what was the training data and the Freeness of the thing."

Thanks to long-time Slashdot reader Robbat2 for sharing the news.

Phoronix reports on Greg Kroah-Hartman's recent slide from his upcoming talk in Paris at Kernel Recipes 2026 (September 21 to 23): With the proliferation of AI/LLM models analyzing the Linux kernel's vast codebase, there has been a surge in the number of CVEs per kernel release. After typically being around 500 CVEs fixed per release, we are now approaching 2,000 CVEs fixed per release and perhaps will break that threshold for Linux 7.3... Fortunately, most often they end up being lower priority vulnerabilities and often within old/obscure driver code, so the impact is often minimal.

The long legal battle over ownership of Linux "is closer than ever to ending," reports the Register, "after a panel of three judges ruled a claim against IBM and Red Hat isn't valid, and that time has expired for further action." In 2021, an heir to SCO settled with IBM for $14.25 million — a sum that reflects the fact SCO had for years failed to produce strong evidence to back its claims. Another of SCO's legal successors, Xinuos, filed a new claim that IBM should be on the hook because Big Blue knew it did not own the code it contributed to Linux but instead had a non-exclusive license to use it. Xinuos argued that when IBM contributed Project Monterey code to Linux [25 years ago], it breached that license.

Xinuos eventually took that argument to the US District Court for the Southern District of New York — and failed to convince it that IBM and Red Hat had a case to answer. Xinuos appealed, and on August 10th the United States Court of Appeals for the Second Circuit decided [PDF] not to revisit the District Court's decision, agreeing that the original legalese governing Project Monterey means it's too late to re-litigate the matter. The Appeals Court also agreed that Xinuos tried to frame the case as a licensing issue but failed, instead arguing that the issue was really about ownership.

That ain't all, folks, because Xinuos intends to file a petition to have the case re-heard by the full bench of the Court of Appeals. That hardly ever happens, unless the court finds significant errors or major legal issues that make a rehearing worthwhile. Law firm Kaplan says the Second Circuit has allowed reviews of less than 0.03 percent of the cases it has handled. So perhaps this matter is now close to a final resolution.
Back in 2000 Slashdot interviewed one of the presidents of SCO.

3,346 backers pledged $1,198,844 on Kickstarter to build the (modular) handheld Linux computer, the Mecha Comet. It's slightly bigger and heavier than your smartphone, with a 4-inch AMOLED display and loaded up with things like microphones, speakers, a SIM tray, two USB ports and a mini HDMI port. There's three separate kill switches for wifi, microphone and camera — plus a "boot mode" switch for the SD card, and even three pins for instant access to its debug console.

It's now expected to ship in October or November (and is still available for preorder).

Snap-in extensions include a keyboard (with programmable colors for its backlit keys), a gamepad, and a special IO Breakout that exposes the 40 pogo pins for modules, sensors, and MCUs. They're all open hardware, and founder Shoaib Merchant says "I'm looking forward to more community designs over the upcoming months." He shows the screen in action in a video on Kickstarter, demonstrating native apps like Music, Notes, Settings, and Files — as well as a Terminal app running on its color screen.

A Linux correspondent at How-To Geek notes its ships "with a custom, hardware-optimized Linux distro out of the box," so "it's like having a dedicated Linux terminal in your pocket." And they argue the new device "could be the future of Linux smartphones." I should also mention that you don't necessarily have to use the battery; it can power on over USB PD without one. Overall, you're getting the same I/O you'd expect from a computer in a smartphone-like form factor, complete with modular input devices — and it's running Linux under the hood. For me, that's the most innovative gadget I've seen in the Linux hardware space in a long time...

It's powerful enough to run most Linux terminal apps, which opens up a lot of possibilities. You're also getting an NPU built right into the SoC, which opens up the possibility for on-device AI workflows — something not possible in budget smartphones. Now, I personally plan to use it for SSHing into my main computer and home lab and operating them remotely. That's also why I'll be putting the LTE modem in the M.2 slot rather than an SSD — mobile data means I can reach my machines even when there's no Wi-Fi around.

I also showed it to my partner, and she sees this as the ideal minimalist phone for digital detoxing. There's a built-in media player, a basic notes app, and you can even run Spotify from the terminal if you want.

Debian developers are voting on whether to ban AI-assisted contributions, reports the blog Linuxiac, with a ballot listing eight proposals and a "None of the above" option. The first one is still the original proposal to ban LLM-assisted contributions by changing the Debian Social Contract. This would stop generative AI from being used for direct Debian work like packaging, software, documentation, translations, websites, and project communication. However, upstream projects made with AI help would not be affected. The proposal gives several reasons for the ban, such as unclear copyright and licensing, doubts about the reliability of AI-generated work, extra review work for maintainers, aggressive scraping of Free Software resources, and the high resource use of large AI systems...

The second option would clearly allow contributions that are partly or fully made by an LLM, as long as contributors check their technical quality, security, licensing, and usefulness, fully understand the changes, and disclose major AI help. It would also ban sending private or sensitive Debian information to untrusted external AI services. A similar fourth option recognizes worries about generative AI but says banning it would be hard to enforce and not helpful. This proposal would accept AI-assisted Debian work if it follows the Debian Free Software Guidelines, is properly reviewed and understood by the contributor, and is marked as AI-assisted when needed. The fifth proposal is even more open. It says Debian should not support or ban generative AI tools, but should apply the same standards for quality, correctness, maintainability, and legality to all contributions, no matter how they were made...

One unique proposal is called "Debian is created by humans." Instead of banning AI tools for contributors, it focuses on what actually gets included in Debian. With this approach, contributors could use generative AI for research, analysis, exploration, or critique, but could not submit AI-generated output directly as Debian packaging, patches, documentation, bug reports, project communications, or other Debian work. As the proposal says: humans create Debian. Another, much stricter proposal asks Debian contributors to avoid LLM use as much as possible. It would require all Debian communication, like bug reports, mailing-list messages, Salsa discussions, and Planet Debian posts, to be written only by humans. Any AI use in Debian work would have to be disclosed, and violations could be handled under the project's Code of Conduct.
The CEO/founder of AI-native compliance management platform company Strike Graph believes a Debian AI ban is "the wrong fix for the actual problem" at hand, reports The New Stack: "Debian's ban isn't really about banning AI," [CEO Justin] Beals says. "It's an admission that nobody has built a reliable way to verify what an AI agent actually produced before it lands in a codebase this many systems depend on, including infrastructure running in orbit. That's a legitimate thing to be worried about...." He thinks that any policy statement that says AI isn't allowed simply won't hold up, as the tooling keeps getting harder to detect...

Looking across the complete set of tabled propositions, proposal A (no LLM contributions to Debian via social contract) needs a 3:1 majority to pass; the other seven proposals (B to H) need a simple majority.