Ancient Slashdot reader alanw shares a post from the OSS Security mailing list, where sysadmin Jan Schaumann wonders what to do after the Linux kernel cranked out 432 CVEs in a little over 24 hours: "I understand the position that CVEs were always a flawed way to track or prioritize security changes... But this onslaught really shows it's not feasible to attempt to prioritize individual kernel changes. I'm not sure what to do here going forward." The Register reports: The nixCraft team speculated on social media that AI bug reports are a likely reason for all those kernel CVEs, which wouldn't be without precedent - Linus Torvalds himself said in May that the Linux kernel security mailing list had become "almost entirely unmanageable" due to AI-assisted bug hunting. Nonetheless, Torvalds has described AI as a useful tool for Linux development while still noting it can be a drag for maintainers, both from a workload standpoint and the fact "it keeps finding embarrassing bugs." [...]

Unfortunately for Linux sysadmins, the position in which they find themselves in this current mess isn't one that's readily solved. CVEs might be a messy way to track and prioritize security updates, especially when hundreds of them are published over a short period, but without something better, it falls to IT and security teams to determine which vulnerabilities affect their systems and which kernel updates they need to deploy. Senior kernel maintainer Greg Kroah-Hartman replied to Jan's post, pushing back on the idea that the kernel's CVE volume is uniquely unmanageable. The kernel isn't special, he argues -- companies everywhere are finally realizing they need to re-evaluate how they update all of their systems and devices, something that's traditionally been "woefully ignored."

On the "just always update" approach, Greg says that's precisely what the kernel community endorses: "This is what the kernel developer community recommends and supports. If you want support from us, do this." Can't manage it yourself? Pay a company for support, or "just use Debian or Yocto as their security practices are amazing." He points to Android as proof the approach scales, calling it "the largest deployment of software in the world" -- billions of devices kept updated "with one very-overworked developer guiding it all."

As for reviewing every CVE individually, he notes this can be largely automated by intersecting the files a CVE touches with the files you actually build, which typically trims the relevant set "down to about 10% of the overall total" -- the approach enterprise distros already take for their customers. Panic-mode selective patching gets a blunt "Good luck with that!" -- regulations like the EU's Cyber Resilience Act are set to legislate that habit away ("rightfully so," in his view), and "your insurance company might wish to have a talk with you as well."

Greg also warns the flood isn't over: "The number of llm-found issues is only on the rise right now, it's going to be a very long 18 months at the least to dig ourselves out of this mess, and people had BETTER be updating their systems all along the way if they expect to be secure in any way." As for the 432-CVE burst itself, he explains it was simply him catching up on a weeks-old, publicly visible review queue over the weekend -- delayed by "a perfect storm of 6 weeks straight of conferences and vacations" -- so it shouldn't have come as a surprise to anyone watching the public git repo.

ZDNet reports on June's Open Source Summit India 2026 in Mumbai, where Linux stable kernel maintainer Greg Kroah-Hartman gave a talk titled "Rust and Linux: How the Rust Language is Going to Help Linux Succeed." Kroah-Hartman said in his keynote that "the [Linux] kernel is moving toward Rust. Git is moving toward Rust. Lots of projects are starting to move toward Rust."

He didn't always feel that way. Kroah-Hartman added, "A number of years ago, when a friend of mine said, 'Ah, you got to try this new language. It's called Rust.' I was like, 'What? No, C is great.' His friend continued, "'No, no, no! It makes programming fun again.' I'm like, 'Nah, programming is fun in C.' He was right. I should have done it then. Rust is actually fun. It makes programming fun. It takes a lot of stuff away from having to worry about the compiler, which can fix a lot of your problems for you, and it makes code a little bit better."

So, Kroah-Hartman has moved from being a Rust skeptic to one of its strongest champions inside the kernel. He now regards Rust as a permanent part of Linux, not an experiment. His case is straightforward: Rust's ownership and type system can eliminate most of the "stupid little tiny things" that dominate kernel Common Vulnerabilities and Exposures (CVEs), while making life easier for overworked maintainers. "Rust," in short, "makes my life so much easier...." In India, he said Linux sees "about 13 CVEs a day" and has been running at "almost nine changes an hour" for a decade or more. Most of those vulnerabilities, he argued, are not exotic attacks but simple C mistakes — unchecked pointers, forgotten unlocks, and sloppy cleanup paths: "This is what we're fixing 13 times a day. Small, trivial, little bugs like this all the time.... I've seen every CVE the kernel has done in the past 25 years. I think 80% would be gone, just because they would be caught by Rust." The remaining 20% are the logic bugs he'd prefer to focus on...."

Moreover, Rust is becoming the default for new work in key subsystems. "New drivers for some subsystems are only going to be accepted in Rust...." he said. Binder, the Android IPC mechanism at the heart of billions of devices, now has parallel C and Rust implementations in the kernel. The C version "will go away soon," leaving the Rust version "as the bedrock of all Android devices going forward."

Linus Torvalds says the Linux kernel will not ban AI-assisted coding tools, and if anti-AI absolutists have a problem with that, they can "fork it" or "walk away." An anonymous reader quotes a report from Ars Technica: Writing in a lengthy post on the Linux kernel mailing list this week, Torvalds said that "Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away." The statement came amid a lengthy thread arguing about the use of Sashiko, an "agentic Linux kernel code review system" that its creators claim can, in tests, independently find 53.6 percent of the bugs that would end up being fixed by human coders in later commits. But the tool can also waste maintainers' time by sending "false positive" reports of bugs that don't exist, at a rate Sashiko's maintainers estimate is "well within [the] 20% range."

In discussing whether maintainers should be subjected to a flood of these kinds of automated, AI-powered bug report emails (true or false), one poster cited the Software Freedom Conservancy's recent statement that the open source community "should support, not just tolerate, those who outright reject LLM-gen-AI systems" and that "every FOSS contributor deserves self-determination regarding LLM-gen-AI." In the face of that statement, Torvalds said that he rejects those who demand that their open source projects not accept any LLM-generated code or revisions. "We're not forcing anybody to use [LLM tools], but I will very loudly ignore people who try to argue against other people from using it," Torvalds said.

Torvalds said his position on this is a pragmatic one that's "based on technical merit. Not fear of new tools." And when it comes to utility, Torvalds said that "AI is a tool, just like other tools we use. And it's clearly a useful one. It may not have been that 'clearly' even just a year ago, but it's no longer in question today. Anybody who doubts that clearly hasn't actually used it." [...] While Torvalds acknowledged that "AI isn't perfect," he urged detractors to compare the output of these tools to the performance of human code maintainers. "Anybody who points to the problems at AI had better be looking in the mirror and pointing at themselves at the same time," Torvalds wrote. "Because it's not like natural intelligence is always all that great either."

Today, the Linux Foundation launched the x402 Foundation to standardize internet-native payments for AI agents, APIs, and applications, based on Coinbase's contributed x402 protocol. Backed by companies including AWS, American Express, Cloudflare, Google, Mastercard, Stripe, and Visa, the effort aims to make payments work directly over HTTP (assuming users are comfortable letting AI agents handle financial transactions).

"The whole idea is to give agents access to money and, through that financial independence, improve their set of capabilities to pretty much anything on the internet," Lincoln Murr, Coinbase's AI product lead, told CNBC last month when the company announced the protocol. "In the 2010s, every internet company dealt with the transition from desktop and web into a mobile environment. And now in the late 2020s, we're seeing the exact same thing happen where agents are going to be the new primary economic actors on the internet."

"Git and email are the two really only tools I use," Linus Torvalds said at Open Source Summit India 2026. But ZDNet reports that he also shared his thoughts on Rust, C, and patch-checking tools: "I use Google as a way to look things up." He added, "I'm unusual; most of the other maintainers end up using many more tools, and I think a lot of them are starting to use AI tools for patch checking," while he "works at a higher level. I work with people, not tools."

When asked about Rust both in Git and the kernel, he pushed back against hype: "I'm not sure Rust is going to take over the world. I still think Rust is very interesting, [but] I still find C to be a much simpler tool." Torvalds continued, "I'm much more excited about all the tools we have for verification of C," including "automated patch verification tools" and "automated email checking tools for patches like Sashiko." Summing up, Torvalds told the Mumbai audience: "I'm more of a hack-and-slash kind of person, and I still like the raw and simple power of C, and I don't think that's going to change."

Torvalds also warned against overestimating Rust's benefits: "Rust fixes a few easy bugs that you can make in C, but it does not fix the logic errors, right? It does not think for you, and when you write incorrect code, the language does not matter. The end result will be incorrect." On mixed C/Rust code bases, he pointed out that guarantees are limited: "The guarantees that Rust give you only apply in the Rust-only parts of your code base, and wherever you interact with C code, all bets are off," with most Rust code in Linux talking to "core kernel C code" that is "much better quality... because that code has been tested in every single environment."
At the same time, Torvalds pointed out, "some of our big and more high-profile bugs in the kernel lately have been logic errors" rather than the kind of memory errors Rust prevents.

"It was just bad programming, which sadly happens even in carefully maintained subsystems and important kernels that are supposed to be very secure."

Linus Torvalds once said LLMs might bring a 10X increase to programmer productivity. But speaking at Open Source Summit India 2026, he now says that number was "not scientific," reports ZDNet. "That was pulled out of my ass number, obviously." Today, he continued, "we're at the point where hopefully it creates more productivity than it takes away," but "we certainly saw more junk being generated by LLMs than we saw useful code up until the like early this year.... it can actually be a huge drain on resources when it takes humans a lot of effort to figure out that, hey, this machine-generated report was not true." Even now, he said, "most of the good ones require more than just the LLM," because "we've had to push back quite a bit... if you find a bug with an LLM, it's not enough to just ask the LLM to make a bug report and then throw it over the fence to us. We want to see a suggested patch; we want to see the human who ran the LLM act as a kind of back-and-forth."

Torvalds described many AI-generated patches as "mindless band-aid kind of patches... they may fix the immediate problem, but the kind of bug remains, and it just is waiting in the hallway to hit you in another place." For his own toy projects, he uses LLMs as prototypers: "I use them as a way to prototype things... quite often the code is not usable in that form, but it's a great way to try something out," while insisting that for kernel-level fixes, "LLMs, in my experience, have not been at that level yet."

Torvalds acknowledged that some AI-found issues have been "absolutely, stunningly, I mean, interesting in a painful kind of way," especially security problems that "show up in the technology press two days later." Despite the embarrassment, he said, "I'm very much not a shoot-the-messenger kind of person. I think we're much better off with LLMs finding bugs, even when they are embarrassing, and they are things that we should probably have found two decades ago."
Torvalds also said he's using AI "for my own toy projects... Every time I travel to some new place, and this is the first time I've been to India, I send the kids pictures of where I am, and for some strange reason, Godzilla seems to follow me around and gets added to those pictures."

ZDNet notes that Torvalds concluded, "There are many useful and less useful uses for AI," and "I think Godzilla is a great place to stop."

Thanks to Slashdot reader joshuark for sharing the article.

"While KDE and GNOME dominate the landscape, a relative newcomer is starting to make waves with features other desktops still don't fully support," argues XDA Developers: Linux 7.0 was the first release of the kernel to officially support Rust, but COSMIC has been all-in on Rust since the very beginning, and COSMIC 1.1 finally stripped all the leftovers of C language from the desktop. It no longer has any traces of Nautilus (the GNOME file manager), and then there's now a COSMIC-native system monitor to replace the GNOME System Monitor, so you have even fewer chances of being afflicted by C-related problems. [The article calls COSMIC's system monitor "much better at showing detailed information about everything from processes to network and disk usage compared to the GNOME and KDE alternatives."]

Stacking Windows
As someone who used to love following Windows news, one of the most disheartening announcements was when Microsoft gave up on Sets, a feature that essentially turned every app window into a tab you could combine with other apps in the same window. I never thought I'd see that feature again, until COSMIC came along. Simply called "stacking", COSMIC has a feature that is exactly what Sets was supposed to be, though this time, you have more control. By default, apps still open in their proper, typical windows, with a title bar as you'd expect. But if you do want to combine multiple apps into one, you can right-click the title bar (or press Super + S) to enable stacking for that window. Then, simply drag another window over that one to start stacking them as tabs. This essentially gives you a whole new way to create "workspaces", as you can have a single window with all the tools you need, so you don't need to jump between different windows all the time, and you can keep a given window focused on a specific workload, but have multiple apps within it. It's a great reminder of what Microsoft took from us, too.

Tiling, But On Demand
Tiling windows is one of those features some power users simply love, and yes, there are ways to make it happen on KDE and GNOME with third-party apps or extensions, but those aren't ideal. It's an extra step to set them up, and very often they don't play nice with all the features those desktops offer, especially as new updates come out and those tools may have a hard time keeping up with the development of the desktops themselves. COSMIC is fantastic because not only does it have built-in window tiling, it's entirely controllable by the user. You can set any workspace to use tiling or floating windows depending on your preference, all completely independent of each other, and you can also choose the new default behavior for new workspaces so things are always tuned to your preferences. You can turn tiling on or off for a given workspace easily, and of course, even while tiling is on, you can allow certain apps to ignore it and still float above others. Not all these capabilities are exclusive to COSMIC, but to have this kind of feature built in with this level of control is still leagues better than anything KDE or GNOME offer in this regard.
The article argues COSMIC also makes customization extremely simple without stifling your options (like tweaking color options for your desktop). "This desktop environment just keeps getting better, and it's quickly establishing itself as a major competitor to long-standing alternatives."

BrianFagioli writes: The Linux Foundation intends to launch the Open Health Stack Software Foundation, a new vendor-neutral home for the Google Open Health Stack project. Google is contributing the project code and assets while Google.org is providing a $3 million grant. The initiative is also backed by Microsoft, Anthropic, and the World Health Organization, with the goal of building open source, AI-ready digital health infrastructure. Will moving the project under Linux Foundation governance accelerate adoption, or is this simply another foundation that most developers will never interact with? The new project will focus on core HL7 FHIR technologies for healthcare interoperability, the Open Health Stack Player deployment toolkit, and AI Commons -- a model-agnostic healthcare AI initiative being co-developed with the World Health Organization.

A notable part of the announcement is its planned Implementer Program, which aims to give startups, small businesses, and local developers in low- and middle-income countries a formal role in governance. In other words, the effort is not just about building healthcare software standards, but about making sure the people implementing them in underserved markets help shape the project too.

StatCounter's June 2026 data shows Windows made up 56.55% of global desktop OS usage, dropping Microsoft's share below 60% for the first time in years. Linux, meanwhile, reached 4.39%, "one of its strongest recent showings in the company's desktop OS statistics," reports Linuxiac. From the report: Apple's desktop platforms also remain a major part of the picture. StatCounter lists OS X at 11.89% and macOS at 4.48% for June 2026, meaning Apple's combined desktop presence remains comfortably ahead of Linux in the global chart. Chrome OS follows with 1.21%.

Of course, StatCounter's numbers should be read for what they are: web usage statistics, not a direct count of installed operating systems. The company calculates its Global Stats from page views across websites using its tracking code, analyzing details such as browser, operating system, and screen resolution. In other words, the figures reflect measured web activity rather than the number of machines actually installed worldwide.

BrianFagioli writes: Valve has released Proton 11.0-1, a major update to its Windows compatibility layer for Linux that makes more games playable while fixing a long list of bugs affecting existing titles. The release restores compatibility for many EA games after a recent EA App update, moves classics like Resident Evil (1996), Resident Evil 2 (1998), Dino Crisis, and SHOGUN: Total War from Proton Experimental into the stable release, and adds support for games including Gothic 1 Classic, X-Plane 12, Breath of Fire IV, and Deadly Premonition. Valve also fixed crashes in HELLDIVERS 2, restored No Man's Sky VR support, improved Steam Overlay compatibility with EA games, addressed KDE and GNOME desktop issues, and rebased Proton on Wine 11.0 with updated graphics components. The full list of changes can be found here.

Have you ever needed a Linux application which only exists in the Windows world? Long-time Slashdot reader BrendaEM writes: Windows does have a lot of useful app (but smaller than "power apps"). Some of these are closed source, some are open, but they're not all available in Linux yet.

My list would have to contain Gimp Tookit versions of: IrfanView image manager, which I think is unequaled in Linux (though it does work to some extent under Wine). I also miss the full version of 7-Zip, because of its better compression settings, which File-Roller does not provide, though the Linux port p7zip is available (though unnoticed by common distributions). Lastly, I think that Notepad++ would be a good addition to Linux.
That last one drew some pushback from long-time Slashdot reader jesco. "If there's one area where Linux shines, then it's the availability of high-quality text editors. Last time I looked Kate was still pretty nice, and there's Emacs, Vim and Neovim" if you're partial to command lines. But are there any daily-drive apps you still find yourself needing? Share your own thoughts in the comments.

Which apps aren't available on Linux?

Slashdot reader wiredmikey writes: AI security researchers have uncovered a structural security flaw dubbed GuardFall that allows decades-old Bash shell tricks to bypass safeguards in most open source AI coding agents. By exploiting shell behaviors such as quote removal and variable expansion, attackers can hide malicious commands in repositories, README files, Makefiles, or other content consumed by AI agents. If executed — particularly in auto-approve or CI environments—the commands can steal credentials, compromise developer systems, or enable software supply chain attacks. According to researchers at Adversa AI, the 11 popular open source AI coding agents tested, only one successfully blocked all of the Bash trick techniques.

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.