Microsoft has released a public preview of Windows Subsystem for Linux (WSL) containers, adding a built-in command-line tool and API for running Linux containers directly inside Windows applications without third-party software. The update also introduces faster file access, improved networking and memory management, plus integration with Defender, Intune, and VS Code. The Register reports: WSL has always been a handy way to run Linux workloads from Windows, and is particularly convenient for Linux developers who must comply with corporate edicts to use a Windows device. The CLI for end-to-end container workflows furthers this. Microsoft stated, "WSL containers make it easier for developers and organizations to build, test, and run containerized workloads while benefiting from the security, manageability, and integration of the Windows platform."

Alternatively, you could run your preferred Linux distribution natively, but that might not be an option, particularly if an organization is keen on the "security, manageability, and integration of the Windows platform." And this is an important point. WSL's existing Microsoft Defender for Endpoint (MDE) has been updated (in private preview) to be aware of Linux container events, and there are settings in Intune for managing WSL containers. Support is also in a pre-release version of VS Code, where the Docker path in the dev container settings can be changed to wslc.

There is also a new default file system for WSL container that Microsoft claims makes Windows file access twice the speed. So, going from terribly slow to just slow? We'll wait until general availability is reached before passing judgment. There's a new default networking mode to improve compatibility and better memory reclaim techniques. However, none of these tweaks will be enabled by default in WSL. Microsoft wrote, "Since these changes touch mission critical paths like file system access and network, for now they are enabled just in WSL container."

BrianFagioli writes: The Linux Foundation has announced Akrites, a new initiative to coordinate vulnerability disclosure and remediation for critical open source software as AI dramatically speeds up vulnerability discovery. Founding members include AWS, Google, Microsoft, OpenAI, Red Hat, NVIDIA, IBM, Cisco, JPMorganChase, and others. Akrites will provide a shared Security Incident Response Team (SIRT), a standardized coordinated vulnerability disclosure process, and act as a "maintainer of last resort" for abandoned but widely used packages.

The goal is to reduce duplicate reports, avoid conflicting patches, and help upstream maintainers address vulnerabilities before they can be exploited. As AI makes it easier to find security flaws, can a coordinated industry effort help protect open source, or does it risk giving large corporations too much influence over the ecosystem? "Akrites is the largest coordinated effort in history to create systems and deploy tooling that leverages the collective power of the community to make everyone safer," the Linux Foundation said in an open letter. "Akrites participants will contribute engineering resources; work to build and ship fixes; or fund the engineers who do. Some companies have contributed mightily already. The reality is, collectively, we need to contribute more."

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.

Linux stable kernel maintainer Greg Kroah-Hartman says Rust can help Linux deal with a flood of AI-discovered security bugs (namely Dirty Frag, Copy Fail, and Fragnesia) by preventing common C mistakes around memory, locking, error handling, and untrusted data at build time rather than during human review. It's "not a silver bullet" and does not mean rewriting the whole kernel, but he said new drivers and subsystems will increasingly use Rust as Linux evolves forward. ZDNet reports: Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it." Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."

Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever." Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."

[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly." Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."

California lawmakers are moving to exempt most open-source operating systems from the state's upcoming age-verification law after backlash from Linux and privacy advocates who warned that the original rules could force decentralized projects to collect users' ages. The amendment would likely shield major Linux distributions, though SteamOS and other Linux-based platforms tied to proprietary app stores may still face compliance questions. Tom's Hardware reports: Assembly Bill 1856 (AB 1856), currently moving through California's legislature ahead of committee reviews in June, would amend the state's earlier age-assurance law by excluding software distributed under licenses that allow users to "copy, redistribute, and modify the software." The proposed amendment specifically states: "Operating system provider" does not mean a person or entity that distributes an operating system or application under license terms that permit a recipient to copy, redistribute, and modify the software.

The amendment follows months of backlash after California passed the original Assembly Bill 1043 (AB 1043), formally known as the Digital Age Assurance Act, in late 2025. The law sought to shift online age verification away from individual websites and apps and down to the operating-system level instead. Under the original law, operating systems would be required to request a user's age or birth date during device setup, then expose an "age bracket signal" to apps and app stores. The law, which defined brackets such as "under 13," "13-15," "16-17," and "18+," immediately raised questions about how such requirements would apply to decentralized, open-source software ecosystems. [...]

AB 1856 does not repeal the original Digital Age Assurance Act. Instead, it narrows the definition of who qualifies as an "operating system provider" under the law. Commercial platforms with proprietary app ecosystems could remain subject to California's age-assurance requirements even if most open-source Linux distributions are ultimately exempted. California Assembly Member Buffy Wicks introduced the amendment on February 11, 2026. However, the open-source exemption language appeared in later revisions that began drawing attention across Linux and privacy communities. The latest version is dated May 18, 2026, and as of May 19, 2026, the bill was read a second time and ordered to third reading.

The It's FOSS blog has news about the Linux Vendor Firmware Service, which gives hardware vendors a secure portal to upload firmware updates "which can then be downloaded and installed by users through clients such as GNOME Software or fwupdmgr." (Originally developed in 2015 by GNOME maintainer Richard Hughes...) The issue, however, obviously, had been funding with the largest contributors being the usual suspects, Framework and Open Source Framework Foundation, at $10K a year. Recently, however, Lenovo and Dell joined suite as Premier sponsors, which is the highest tier at $100K a year each, making the project more sustainable and manageable.

These companies contributing makes a lot of sense, considering they are two of the bigger computer companies which offer Linux by default in some cases, especially with Lenovo's ThinkPads being the Linux users' favorite for decades. And now... HP has followed suit as a Premier sponsor, also providing $100K a year, right alongside Dell and Lenovo...

The question still remains, however, where are the other vendors? What are they waiting for... This major move by these three companies should not only be seen as a sign of relief and wider acceptance of the usage of Linux, but as a beacon for other vendors to follow, who ought to make their hardware more accessible to the open-source community.