With the price of the new Steam Machine starting at $1,049, you might want to consider making your own Steam Machine instead. An anonymous reader quotes a report from The Verge: Valve says that "starting with the SteamOS 3.8 release, you can put together your own Steam Machine using whatever PC parts you want." SteamOS 3.8.10 launched last week with a slew of updates, including "improved compatibility with recent Intel and AMD platforms." Alongside that improved compatibility, Valve is giving gamers the green light to install SteamOS on their own desktops. In an interview with The Verge, Valve's Pierre-Loup Griffais said Valve has been "rolling out improvements to [SteamOS] so it's more compatible with desktop hardware," including eventual support for Nvidia graphics. Griffais says Valve has "a growing team" working on Nvidia driver support for SteamOS, adding, "We're collaborating with Nvidia very closely." While he mentioned that Nvidia support might not come this year, Griffais emphasized that "it's certainly something that we're working on in the background."

It's technically been possible to run SteamOS on your own hardware for a while now, but compatibility has been mostly limited to AMD systems. So far installing it has also required using a Steam Deck recovery image, a process that, speaking from experience, is much less straightforward than the installation process for most other Linux distributions. Trying to run SteamOS on Intel or Nvidia hardware has not been easy so far. According to Griffais, Valve is working to change that, which could mean that down the line, you'll be able to run SteamOS on just about any gaming PC hardware you want, including Nvidia.

For the more immediate future, Griffais says SteamOS in its current state should offer a "good experience" on console-like PC setups: "If you have something that is similar to the use case of a Steam Machine, where you have a PC that's gonna be plugged into a TV, and has a single hard drive that you're not going to try and dual boot [] you can put SteamOS on there, and you'll have an experience that is very similar to a Steam Deck docked or a Steam Machine, with some caveats, of course," like a lack of HDMI-CEC support. But "the core bits of the experience are there. The SteamOS graphics driver, the shader precompilation [...] you can get at all of that with the SteamOS." Griffais says SteamOS does not yet offer an easy way to dual-boot alongside Windows or another operating system, but envisions "a time where it's a better experience to install on your desktop and have it coexist with a different operating system."

The blog Linuxiac reports: A new systemd fork has appeared with a specific purpose: removing systemd's recently added support for storing a user's birth date in JSON user records.

The fork, called Liberated systemd, published its first tagged release as v261 shortly after the official systemd 261 release. In other words, the fork follows upstream systemd while reverting the change that added the new optional birthDate field.

Importantly, this is not a new init system, a wider redesign of systemd, or a general-purpose alternative to the upstream project. Its stated purpose is to remain close to upstream systemd while removing what the author describes as "surveillance enablement"... The author recommends testing the fork in a virtual machine before using it on real hardware and warns nightly builds are more likely to be unstable than named releases.

Tech Times reports: Linux 7.2's merge window closed out a cleanup campaign on Friday that most kernel developers had stopped expecting to see end: the complete removal of strncpy(), a C string-copy function that the kernel's own documentation labels "actively dangerous," from every subsystem, driver, and architecture-specific file in the kernel source tree.

The merge landed June 20, 2026. After around 362 commits spread across six years of incremental work, no call site using the function remained, and the function itself — including the last per-CPU-architecture optimized implementations — was struck from the source. The removal matters beyond housekeeping. strncpy() is a persistent source of a specific class of memory error: kernel buffers that contain sensitive data can leak bytes past an unterminated string boundary, a pattern that enables memory disclosure vulnerabilities. Eliminating the function from the tree removes that entire class from the kernel's attack surface — and, critically, makes strncpy() unavailable to any future contributor, turning a best-practice suggestion into an enforced policy.
Phoronix notes it's replaced by five different functions: In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies.
"The reason five functions were needed," explains Tech Times, "is that different parts of the kernel were using strncpy() for five semantically distinct memory operations — each with a different intent, different termination requirement, and different padding behavior. " The original function obscured all of those differences under a single ambiguous name. The 362-commit campaign to replace it was, in effect, a codebase-wide audit that forced every call site to declare its actual intent in code That is an engineering outcome with lasting value: the kernel's string-handling semantics are now explicit where they were previously implicit, and future maintainers can read a function name and understand what a copy operation actually does.

This week the Ubuntu desktop's director of engineering announced they're bringing speech-to-text dictation to Ubuntu Desktop, aiming for an experience "that feels like a natural part of the desktop while respecting user privacy and running entirely on local hardware."

"Speech recognition has become a common feature on modern platforms, and we think it should be a first-class experience on Ubuntu Desktop as well."

More details from the blog It's FOSS: For Ubuntu 26.10, the initial version of Myna is expected to be a desktop dictation tool built around GNOME on Wayland with a push-to-talk mechanism gatekeeping when your microphone accepts input. Using it means holding a hotkey, speaking, and letting go. A small activity indicator shows while it is listening, and the transcribed text lands wherever the cursor was sitting when dictation started.

Recognition itself happens inside a sandboxed component called the Canonical Inference Snap, while a Speech Orchestrator manages the session and an Audio Adapter handles whatever the microphone picks up, denoising and chunking it before it ever reaches the model... Speech recognition will happen locally, and an internet connection is not needed once the appropriate model is installed... The audio data won't be sticking around either, being stored in a small in-memory buffer that gets discarded the moment the session ends. Features like dictation into password fields, wake words, continuous listening, voice assistants, voice commands, translation, speaker identification, and automatic language detection are all off the table...

You should also know that Canonical is looking for feedback before the specs for Myna are finalized, especially from people who already rely on dictation or assistive tools on Linux.

BrianFagioli writes: Google, Microsoft, OpenAI, Arm, Mastercard, Siemens, and other companies have joined the newly launched Appia Foundation under the Linux Foundation. The project aims to create common specifications and assessment frameworks that organizations can use to demonstrate AI systems meet emerging safety, trust, and compliance requirements. According to the Linux Foundation, the framework is designed to allow conformity evidence to be reused across the AI supply chain, potentially reducing duplicate assessments and compliance costs. The announcement comes as governments around the world move toward enforcing AI regulations and organizations face increasing pressure to prove AI systems are trustworthy. "As international standards and legal frameworks become more established, global organizations need a consistent, practical way to verify that AI systems conform to new expectations," said Jim Zemlin, CEO of the Linux Foundation. "The Appia Foundation establishes a neutrally governed environment where the entire industry can collaborate on a common assessment framework. By building this infrastructure in the open, we are helping organizations reduce complexity, lower operational costs and build trust."

Craig Shank, Executive Director of the Appia Foundation, added: "AI systems now make decisions about people's loans, their children's schools and their jobs. People on the receiving end deserve to know those systems were built and assessed against criteria that hold up to scrutiny. The Appia Foundation was formed to do that work: creating publicly available specifications that organizations across the AI value chain use to demonstrate their systems meet those criteria. By establishing this open framework, we are building the accountability layer required to scale safe and trusted AI across major industries."

The Arch Linux User Repository "AUR" is facing another issue just days after more than 1,500 packages were found carrying malware. According to Phoronix, over 70 AUR packages have reportedly been modified to insert Russian spam and profane messages into users' shell configuration files. From the report: Nicolas Boichat with his AI/LLM detection bot detected some questionable messages appearing in AUR content. Russian messages were being added post-install to the bashrc / zshrc / Fish configuration, etc containing offensive messaging. Those commits happened on the 14th, after the recent malware fiasco. And then over the past day reporting on dozens of AUR packages having similar Russian messages containing offensive language.

The latest update on that thread indicates more than 70 AUR packages having this Russian spam / offensive messaging. Among those various Python packages, Ruby packages, Llama.cpp, and others. At least the AI/LLM bots are proving helpful here in proactively picking up on some of the AUR abuses until the fundamental situation can be better handled.

Phoronix reports: The AMD R600 Gallium3D driver saw 59 commits [last] Sunday to Mesa 26.2. Making this code restructuring and code cleaning all the more notable is that the improvements to this old AMD Radeon graphics driver was done in part by GitHub Copilot.

Gert Wollny has been among the few open-source developers left working on the AMD R600g driver that covers from the Radeon HD 2000 series through Radeon HD 6000 series graphics cards... [T]he old open-source GPU driver support is being assisted by AI long after the upstream vendor has stopped working on this driver — the Radeon HD 2000 "R600" series launched in 2007.

More than 1,500 user-contributed packages in the Arch Linux User Repository "AUR" were infected with malware, reports Phoronix: The last message in the thread over this security incident is noting that Arch Linux developers have deleted all the malicious commits they are aware of. Cited was this list that puts the number of malware-affected packages at 1,579...

Even at 1,579 packages listed, that final updated noted, it's a "list containing many (but not all) of the affected packages".
Thanks to long-time Slashdot reader couchslug for sharing the report.

The Asahi Linux team is warning Apple Silicon users not to upgrade to the macOS 27 beta because Apple's changes to the boot picker and Startup Disk app make Asahi partitions invisible, preventing Linux from booting. The Register reports: The team added: "If you insist on trying out macOS 27 as soon as possible, please ensure you install a secondary copy of macOS 26 first, or install macOS 27 itself on a secondary volume." They've also updated the installer to prevent installs from running on macOS 27 for now. For anyone who ignored all of the above, "we will not support users who have installed the macOS 27 beta without ensuring at least one stable version of macOS is installed."

Considering macOS 27 is in beta, the issue may be accidental rather than an attempt by Apple to block Linux on its hardware. The Asahi team said it has filed bug report. The good news for anyone who pulled the trigger on installing the macOS 27 beta is that although the partition might not be visible, it hasn't gone anywhere. The Asahi team wrote: "If you have already upgraded to the beta and noticed that your Asahi partition has disappeared, do not stress. Your Asahi partition is still there, and you have not lost any data."

An anonymous reader quotes a report from Ars Technica: Researchers have analyzed a high-severity vulnerability in Linux that's able to escalate untrusted users to root by exploiting a bug you don't often see: a single errant character inside the kernel. The vulnerability, tracked as CVE-2026-23111, is located in nf_tables, a subsystem of the Linux kernel that provides packet filtering capabilities. It's used to manage firewall rules and replaces older subsystems such as iptables, ip6tables, arptables, and ebtables.

The presence of a single mis-issued exclamation point in code implementing nf_tables introduced a use-after-free, a class of vulnerability that corrupts memory by placing malicious code at memory addresses that haven't been properly freed of their previous contents. CVE-2026-23111 can be exploited by an unprivileged user or process to elevate system rights to root. The exploit works by disrupting the deletion of verdicts -- a determination within the nf_tables framework that determines if a packet matches a rule calling for a certain action to be performed. This process can use what are known as catchall elements, which act as a wildcard in the event a lookup doesn't match any other element in the set.

When a verdict map is deleted from memory, catchall elements are deactivated and a chain's reference counter is decremented. When errors occur the deletion can be reversed and the counter incremented. CVE-2026-53111 allows for that process to be altered. As a result, the exploit can decrement the variable an arbitrary number of times and then delete and free the chain when some objects still point to it. Although the kernel vulnerability was fixed in February, multiple proof-of-concept exploits have since emerged, including one from FuzzingLabs in April and another from Exodus Intelligence that works on Debian and Ubuntu.

BrianFagioli writes: Fedora Linux 43 users upgrading to the latest Dovecot mail server discovered something rather unsettling: some older Microsoft Outlook configurations may have been silently ignoring SSL/TLS settings for POP3 email connections for years. According to a Fedora community blog post, affected Outlook clients reportedly continued using insecure port 110 connections even when encryption was enabled in the application settings. The issue surfaced after Dovecot 2.4 disabled plaintext authentication on non secure connections by default, causing Outlook users to suddenly lose mailbox access after the Fedora 43 upgrade.

The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.

An anonymous reader quotes a report from Ars Technica: Microsoft's Build developer conference kicked off today, and as with almost everything the company has done in the last few years, Microsoft's opening keynote focused overwhelmingly on AI and other closely related technologies. [...] On the hardware front, we didn't get any updates for existing Surface devices (not counting yesterday's Surface Laptop Ultra announcement), but we did get something new: the Surface RTX Spark Dev Box is "a compact developer PC" built around Nvidia's new RTX Spark chip with up to 128GB of built-in memory. The Dev Box looks a little like a cartoon anvil or piano fell onto an Xbox Series X and flattened it. Its aluminum casing was designed "to double as a heatsink," and its preloaded version of Windows 11 Pro will include a "purposeful" set of developer-centric default settings and preinstalled tools.

This is a follow-up of sorts to the Windows Dev Kit 2023, also known as "Project Volterra." This Qualcomm Snapdragon 8cx Gen 3-powered PC was essentially the system board from a Surface Pro tablet stuffed into a plastic box, and it was introduced alongside Arm-native versions of several Microsoft developer tools. It helped to set the stage for the Arm-based flagship Surface devices that launched the next year, which benefitted from a better and faster x86-to-Arm code translation technology called Prism and a greater number of Arm-native third-party apps that didn't need to be translated in the first place. Microsoft didn't announce pricing or specific specs for the RTX Spark Dev Box, but you can probably expect it to cost quite a bit more than the $600 that Project Volterra did. Hopefully, Microsoft can keep the price at least somewhat lower than the $4,699 asking price for Nvidia's similarly specced DGX Spark box.

On the software side, several developer-centric changes are coming to Windows 11, particularly for users of the Windows Subsystem for Linux (WSL). Microsoft is introducing a Windows-native version of the coreutils command line tools, so that commands or scripts made for Linux work within Windows and the other way around; the ability to run WSL inside of containers, said to be arriving in "the coming months"; and something called Windows Developer Configurations that uses the WinGet tool to quickly set up "a distraction-free dev environment with VS Code, GitHub Copilot, WSL, PowerShell 7 and developer-optimized settings with one command on any Windows 11 device." Microsoft also introduced Microsoft Execution Containers (MXC), as "enterprise-grade sandboxed environments" that let AI agents like OpenClaw operate on Windows without getting unrestricted access to the whole system. In theory, MXC could let organizations enforce agent-specific limits, such as blocking access to personal accounts, separating work and personal data, or requiring permission before deleting files.

The MXC GitHub repo also notes support for "multiple containment backends," meaning the same sandboxing concept could apply beyond AI agents to other plugins, tools, and workloads.

Further reading: Microsoft Unveils Scout, an Autonomous AI Agent Built On OpenClaw

Aikido Security says more than 30 official @redhat-cloud-services npm packages were compromised with a credential-stealing worm called "Miasma," a variant resembling the open-sourced Mini Shai-Hulud supply-chain malware. "The packages were published via GitHub Actions OIDC, indicating the CI/CD pipeline was compromised rather than an npm token," the report says. "If you have installed any affected package versions since June 1, 2026, treat all CI secrets, cloud credentials, SSH keys, and npm tokens as compromised and rotate them immediately." From the report: Each compromised package declares a preinstall script in its package.json that executes node index.js automatically on every npm install, before any application code runs and before the developer has any indication something is wrong. The index.js file is 4.2 MB payload hidden behind multiple layers of obfuscation.

As with previous Mini Shai-Hulud attacks, the payload performs a broad credential sweep across cloud providers, CI/CD environments, and developer tooling. On the CI side it targets GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN. For cloud credentials it collects AWS access keys and session tokens, GCP application default credentials and service account key files, and Azure service principal credentials and managed identity tokens. It also sweeps for HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, GPG keys, and any .env files it can find across the filesystem.

The Linux kernel mailing list has a new patch proposing the retirement of the x32 ABI, reports Phoronix: The Linux x32 ABI for x86_64 processors allow making use of the full 64-bit register file and wide data path but retaining 32-bit pointers to provide for a smaller memory footprint when not needing 64-bit pointers. Linux x32 came to the party late and didn't enjoy much adoption over the years and is now looking at possible removal from the Linux kernel. The x32 code was a nice concept for helping lower memory footprint requirements while otherwise making use of the x86_64 capabilities, but with its limited adoption and x86_64 simply being the de facto standard these days, Linux kernel developers are looking at phasing out the x32 ABI. The x32 ABI was added in Linux 3.4 back in 2012 plus also required updated compiler support too.
The proposed patch argues "there is practically no real use for x32," noting that some Linux vendors (like Debian) already disable x32 by default to reduce attack surfaces. "Should nothing happen within the next half year, lets remove code bits around August after the summer break."

Discussions about dropping x32 support first started in 2018...

IBM and Red Hat are committing $5 billion to a new initiative called "Project Lightwell," which aims to secure open-source software supply chains with AI-assisted vulnerability discovery, triage, patch validation, and upstream maintenance. Longtime Slashdot reader wiggles shares a press release from IBM: IBM and Red Hat today announced Project Lightwell, a $5 billion commitment backed by new frontier AI capabilities and a global force of more than 20,000 engineers to help enterprises secure open source software. Together, these investments establish a new model for enterprise use of open source software, from upstream development through production environments.

Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.

IBM and Red Hat have already begun collaborating with a select group of early adopters on Project Lightwell, including Bank of America, BNY, Citi, Goldman Sachs, JPMorganChase, Mastercard, Morgan Stanley, Royal Bank of Canada, State Street, Visa and Wells Fargo. The real-world insights from these initial deployments will actively shape how vulnerabilities are identified, validated, and remediated at scale across complex software supply chains.