Mark Tyson writes via Tom's Hardware: On this day 34 years ago, an unknown computer science student from Finland announced that a new free operating system project was "starting to get ready." Linus Benedict Torvalds elaborated by explaining that the OS was "just a hobby, [it] won't be big and professional like GNU." Of course, this was the first public outing for the colossal collaborative project that is now known as Linux. Above, you can see Torvalds' first posting regarding Linux to the comp.os.minix newsgroup. The now famously caustic, cantankerous, curmudgeon seemed relatively mild, meek, and malleable in this historic Linux milestone posting.

Torvalds asked the Minix community about their thoughts on a free new OS being prepared for Intel 386 and 486 clones. He explained that he'd been brewing the project since April (a few months prior), and asked for direction. Specifically, he sought input about other Minix users' likes and dislikes of that OS, in order to differentiate Linux. The now renowned developer then provided a rough summary of the development so far. Some features of Linux that Torvalds thought were important, or that he was particularly proud of, were then highlighted in the newsgroup posting. For example, the Linux chief mentioned his OS's multithreaded file system, and its absence of any Minix code. However, he humbly admitted the code as it stood was Intel x86 specific, and thus "is not portable."

Last but not least, Torvalds let it be known that version 0.01 of this free OS would be out in the coming month (September 1991). It was indeed released on September 17, 1991, but someone else decided on the OS name at the last minute. Apparently, Torvalds didn't want to release his new OS under the name of Linux, as it would be too egotistical, too self-aggrandizing. He preferred Freax, a portmanteau word formed from Free-and-X. However, one of Torvald's colleagues, who was the administrator for the project's FTP server, did not think that 'Freax' was an appealing name for the OS. So this co-worker went ahead and uploaded the OS as 'Linux' on that date in September, without asking Torvalds.

"Some joyless ne'er-do-well has loosed a botnet on the community-driven Arch Linux distro," reports the Register, with a distributed denial of service (DDoS) attack that apparently started a week ago.

Arch maintainer Cristian Heusel announced Thursday on the project's web site that the attack "primarily impacts our main webpage, the Arch User Repository (AUR), and the Forums." We are aware of the problems that this creates for our end users and will continue to actively work with our hosting provider to mitigate the attack. We are also evaluating DDoS protection providers while carefully considering factors including cost, security, and ethical standards... As a volunteer-driven project, we appreciate the community's patience as our DevOps team works to resolve these issues.
A status update Friday acknowledged "we are suffering from partial outages." The Register reports: The attack comes as the project has been enjoying a boost in mainstream success. The distro was picked by Valve to underpin the SteamOS software running on its Steam Deck handheld gaming gadget, with the company providing the project with funding for further development. Late last year, a new version of the archinstall tool was released, with a view to making the system more friendly to newcomers...

For now, the Arch team is working to mitigate the attack's impact, which highlights a bootstrapping issue. Tools designed to shift traffic to mirrors in the event the main infrastructure is unavailable rely on a mirror list obtained from that same main infrastructure, with Heusel advising that users should "default to the mirrors listed in the pacman-mirrorlist package" if tools like reflector fail. Installation media can be downloaded from a range of mirrors, too, but should be checked against the project's official signing key before being trusted.

BrianFagioli shares a report from NERDS.xyz: LibreOffice 25.8 has landed, and while it packs in new features and speed improvements, the biggest headline is who just got left behind. If you are still running Windows 7 or Windows 8/8.1, this is the end of the road. LibreOffice will not run on those systems anymore, and there are no workarounds. The suite has slammed the door shut.

For years, LibreOffice kept older Windows users afloat while Microsoft and other developers moved on. That lifeline is gone. Anyone stubbornly clinging to Windows 7 or 8 now has two choices: upgrade or stay stuck on outdated software. LibreOffice has made it clear that it will not carry dead platforms any further. And the cuts do not stop there. 32-bit Windows builds are on their way out, with deprecation already in place. On the Mac side, 25.8 is the last release that runs on macOS 10.15. Starting with LibreOffice 26.2, only macOS 11 and newer will be supported. In other words, if your computer is too old to run modern systems, LibreOffice is walking away.

An anonymous reader writes: Kaisen Linux, a Debian-based distro packed with tools for sysadmins, system rescue, and network diagnostics, is shutting down. This comes not long after Intel's Clear Linux also reached the end of the road.

Kaisen offered multiple desktop environments like KDE Plasma, LXQt, MATE, and Xfce, plus a "toram" mode that could load the whole OS into RAM so you could free up your USB port. The final release, Rolling 3.0, updates the base to Debian 13, defaults to KDE Plasma 6, replaces LightDM with SDDM, drops some packages like neofetch and hping3, and adds things like faster BTRFS snapshot restores, full ZFS support, and safer partitioning behavior.

Unlike Clear Linux, Kaisen will still get security updates for the next two years, giving current users time to migrate without rushing.

The Linux kernel project lacks a formal succession plan for when Linus Torvalds steps down, Register columnist Rupert Goodwins writes. Torvalds has said "there's no need for formality" and that succession will occur naturally through community trust. "The next benevolent overlord will appear naturally," Torvalds believes.

Goodwins calls this approach dangerous, noting that "succession is always a time of uncertainty for those who like the way things are, and opportunity for those who do not." The kernel project faces existing tensions including overstretched maintainers doing "two jobs, the one they're paid for, and the Linux kernel work," commercial pressures from companies like Red Hat, and increasing maintenance burdens from automated bug reports. "Hope, as they say, is not a strategy," Goodwins writes.

An anonymous reader quotes a report from ZDNet: You can't say Linux creator Linus Torvalds didn't give the kernel developers fair warning. He'd told them: "The upcoming merge window for 6.17 is going to be slightly chaotic for me. I have multiple family events this August (a wedding and a big birthday), and with said family being spread not only across the US, but in Finland too, I'm spending about half the month traveling." Therefore, Torvalds continued, "That does not mean I'll be more lenient to late pull requests (probably quite the reverse, since it's just going to add to the potential chaos)." So, when Meta software engineer Palmer Dabbelt pushed through a set of RISC-V patches and admitted "this is very late," he knew he was playing with fire. He just didn't know how badly he'd be burned.

Torvalds fired back on the Linux Kernel Mailing List (LKML): "This is garbage and it came in too late. I asked for early pull requests because I'm traveling, and if you can't follow that rule, at least make the pull requests good." It went downhill from there. Torvalds continued: "This adds various garbage that isn't RISC-V specific to generic header files. And by 'garbage," I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window." Specifically, Torvalds hated the "crazy and pointless" way in which one of the patch's helper functions combined two unsigned 16-bit integers into a 32-bit integer. How bad was it? "That thing makes the world actively a worse place to live. It's useless garbage that makes any user incomprehensible, and actively *WORSE* than not using that stupid 'helper.'"

In addition to the quality issues, Torvalds was annoyed that the offending code was added to generic header files rather than the RISC-V tree. He emphasized that such generic changes could negatively impact the broader Linux community, writing: "You just made things WORSE, and you added that 'helper' to a generic non-RISC-V file where people are apparently supposed to use it to make other code worse too... So no. Things like this need to get bent. It does not go into generic header files, and it damn well does not happen late in the merge window. You're on notice: no more late pull requests, and no more garbage outside the RISC-V tree." [...] Dabbelt gets it. He replied, "OK, sorry. I've been dropping the ball lately, and it kind of piled up, taking a bunch of stuff late, but that just leads to me making mistakes. So I'll stop being late, and hopefully that helps with the quality issues."

New submitter darwinmac writes: Kapitano, a user-friendly GTK4 frontend for the ClamAV scanner on Linux, has been killed by its developer 'zynequ' following a wave of harsh, personal attacks from a user. The tool was meant to simplify virus scanning but quickly became a flashpoint when a user claimed it produced malware.

After defending the code calmly, the developer was nonetheless met with escalating accusations and hostility, leading to burnout. The project is now marked as "not maintained," its code released into the public domain under The Unlicense, and it's being delisted from Flathub.

zynequ said: "This was always a hobby project, created in my free time with none of the financial support. Incidents like this make it hard to stay motivated."

"Linus Torvalds has used his authority to reject the RISC-V architecture changes for the Linux 6.17 kernel," reports Phoronix: Only on Friday were the RISC-V code updates submitted for the Linux 6.17 merge window. The Linux 6.17 merge window is expected to wrap up on Sunday with the Linux 6.17-rc1 release... [T]his pull request has been rejected by Linus Torvalds for Linux 6.17 on the basis of being late in the merge window especially with his international travels this week being known. And he's unhappy with some of the code included as part of this merge request. .
Here's the text of Torvalds' response...


> RISC-V Patches for the 6.17 Merge Window, Part 1

No. This is garbage and it came in too late. I asked for early pull requests because I'm traveling, and if you can't follow that rule, at least make the pull requests *good*.

This adds various garbage that isn't RISC-V specific to generic header files.

And by "garbage" I really mean it. This is stuff that nobody should ever send me, never mind late in a merge window.

Like this crazy and pointless make_u32_from_two_u16() "helper".

That thing makes the world actively a worse place to live. It's useless garbage that makes any user incomprehensible, and actively *WORSE* than not using that stupid "helper".

If you write the code out as "(a
In contrast, if you write make_u32_from_two_u16(a,b) you have not a f%^5ing clue what the word order is. IOW, you just made things *WORSE*, and you added that "helper" to a generic non-RISC-V file where people are apparently supposed to use it to make *other* code worse too.

So no. Things like this need to get bent. It does not go into generic header files, and it damn well does not happen late in the merge window.

You're on notice: no more late pull requests, and no more garbage outside the RISC-V tree.

Now, I would *hope* there's no garbage inside the RISC-V parts, but that's your choice. But things in generic headers do not get polluted by crazy stuff. And sending a big pull request the day before the merge window closes in the hope that I'm too busy to care is not a winning strategy.

So you get to try again in 6.18. EARLY in the that merge window. And without the garbage.


Torvalds' message drew a conciliatory response from the submitter of the patches. "I'll stop being late, and hopefully that helps with the quality issues."

"KDE Linux is an all-new desktop Linux distro being developed as a showcase for the KDE desktop project," reports The Register.

"The project is still in a pre-alpha testing stage, but recently went public on the KDE website. Versions are available to download and try out." KDE Linux is an entirely new and experimental OS. There's lots of room for confusion here, because KDE already has a demonstration distro, KDE Neon. KDE Linux is a totally separate and far more ambitious project. In terms of its underlying design, it's intended to be a super-stable end-user distro. This is in contrast with Neon, which is an experimental showcase for the latest and greatest code. Neon isn't meant to be anyone's daily driver...

Several aspects of [KDE Linux's] design are clearly influenced by Valve's SteamOS 3. Like SteamOS 3, KDE Linux is an immutable distro, with dual read-only Btrfs-format root partitions that update each other alternately... KDE Linux isn't based on Ubuntu or Debian. It's built using Arch Linux, but it's different enough that it doesn't really count as an Arch variant. As an immutable distro, there's no package manager, for instance, so the user can't install Arch packages... You can only install sandboxed apps that go in their own corner of the OS, and here the plan is that users will install Flatpak (and possibly Snap, "if it's not too hard and the UX is OK") packages using the KDE Discover app store. Aside from them, you won't be able to update individual packages. OS updates come as a whole new system image, with all components updated at once.
"This is intended to one day be a bulletproof daily driver, not a demo system, which is the intended purpose of KDE Neon..." the article concludes.

And while their test of current work-in-progress/test version kept crashing, "the promise is considerable, and this could turn out to be one of the most radical end-user distros out there."

Thanks to Slashdot reader king*jojo for sharing the news.

An anonymous reader quotes a report from ZDNet: In an interview, Lansweeper, an IT asset discovery and inventory company, revealed to ZDNET that, in its analysis of over 15 million identified consumer desktop operating systems, it found that Linux desktops currently account for just over 6% of PC market share. This news comes after several other studies have shown the Linux desktop is right around the 6% mark. Indeed, according to the US Federal Government Website and App Analytics count, the Linux desktop market share over the last 90 days has reached 6.3%, a new high. In July, according to StatCounter, the Linux desktop also set a record high by its metrics with 5.24%.

"The July 2025 results of the Steam Survey were posted a few minutes ago," Phoronix reported last night, "and show a healthy 0.32% increase to put the Linux gaming marketshare at 2.89%." That's a recent high in percentage terms and while Steam saw around 3% in the early days of Steam on Linux a decade ago, in absolute terms this is likely the largest surveyed figure ever for the Linux gaming population.

Linux was at 2.89% for July while macOS was at 1.88% and Windows at 95.23%.
There does seem to be a jagged line that's trending upward...

November: 2.03%
December: 2.29%
January: 2.06%
February: 1.45%
March: 2.33%
April: 2.27%
May: 2.69%
June: 2.57%
July: 2.89%

ZDNet's Steven Vaughan-Nichols shares his list of "what's new and improved" in the latest Linux 6.16 kernel. An anonymous reader shares an excerpt from the report: First, the Rust language is continuing to become more well-integrated into the kernel. At the top of my list is that the kernel now boasts Rust bindings for the driver core and PCI device subsystem. This approach will make it easier to add new Rust-based hardware drivers to Linux. Additionally, new Rust abstractions have been integrated into the Direct Rendering Manager (DRM), particularly for ioctl handling, file/GEM memory management, and driver/device infrastructure for major GPU vendors, such as AMD, Nvidia, and Intel. These changes should reduce vulnerabilities and optimize graphics performance. This will make gamers and AI/ML developers happier.

Linux 6.16 also brings general improvements to Rust crate support. Crate is Rust's packaging format. This will make it easier to build, maintain, and integrate Rust kernel modules into the kernel. For those of you who still love C, don't worry. The vast majority of kernel code remains in C, and Rust is unlikely to replace C soon. In a decade, we may be telling another story. Beyond Rust, this latest release also comes with several major file system improvements. For starters, the XFS filesystem now supports large atomic writes. This capability means that large multi-block write operations are 'atomic,' meaning all blocks are updated or none. This enhances data integrity and prevents data write errors. This move is significant for companies that use XFS for databases and large-scale storage.

Perhaps the most popular Linux file system, Ext4, is also getting many improvements. These boosts include faster commit paths, large folio support, and atomic multi-fsblock writes for bigalloc filesystems. What these improvements mean, if you're not a file-system nerd, is that we should see speedups of up to 37% for sequential I/O workloads. If your Linux laptop doubles as a music player, another nice new feature is that you can now stream your audio over USB even while the rest of your system is asleep. That capability's been available in Android for a while, but now it's part of mainline Linux.

If security is a top priority for you, the 6.16 kernel now supports Intel Trusted Execution Technology (TXT) and Intel Trusted Domain Extensions (TDX). This addition, along with Linux's improved support for AMD Secure Encrypted Virtualization and Secure Memory Encryption (SEV-SNP), enables you to encrypt your software's memory in what's known as confidential computing. This feature improves cloud security by encrypting a user's virtual machine memory, meaning someone who cracks a cloud can't access your data. Linux 6.16 also delivers several chip-related upgrades. It introduces support for Intel's Advanced Performance Extensions (APX), doubling x86 general-purpose registers from 16 to 32 and boosting performance on next-gen CPUs like Lunar Lake and Granite Rapids Xeon. Additionally, the new CONFIG_X86_NATIVE_CPU option allows users to build processor-optimized kernels for greater efficiency.

Support for Nvidia's AI-focused Blackwell GPUs has also been improved, and updates to TCP/IP with DMABUF help offload networking tasks to GPUs and accelerators. While these changes may go unnoticed by everyday users, high-performance systems will see gains and OpenVPN users may finally experience speeds that challenge WireGuard.

Cisco has donated its AGNTCY initiative to the Linux Foundation, aiming to create an open-standard "Internet of Agents" to allow AI agents from different vendors to collaborate seamlessly. The project is backed by tech giants like Google Cloud, Dell, Oracle and Red Hat. "Without such an interoperable standard, companies have been rushing to build specialized AI agents," writes ZDNet's Steven Vaughan-Nichols. "These work in isolated silos that cannot work and play well with each other. This, in turn, makes them less useful for customers than they could be." From the report: AGNTCY was first open-sourced by Cisco in March 2025 and has since attracted support from over 75 companies. By moving it under the Linux Foundation's neutral governance, the hope is that everyone else will jump on the AGNTCY bandwagon, thus making it an industry-wide standard. The Linux Foundation has a long history of providing common ground for what otherwise might be contentious technology battles. The project provides a complete framework to solve the core challenges of multi-agent collaboration:

- Agent Discovery: An Open Agent Schema Framework (OASF) acts like a "DNS for agents," allowing them to find and understand the capabilities of others.
- Agent Identity: A system for cryptographically verifiable identities ensures agents can prove who they are and perform authorized actions securely across different vendors and organizations.
- Agent Messaging: A protocol named Secure Low-latency Interactive Messaging (SLIM) is designed for the complex, multi-modal communication patterns of agents, with built-in support for human-in-the-loop interaction and quantum-safe security.
- Agent Observability: A specialized monitoring framework provides visibility into complex, multi-agent workflows, which is crucial for debugging probabilistic AI systems.

You may well ask, aren't there other emerging AI agency standards? You're right. There are. These include the Agent2Agent (A2A) protocol, which was also recently contributed to the Linux Foundation, and Anthropic's Model Context Protocol (MCP). AGNTCY will help agents using these protocols discover each other and communicate securely. In more detail, it looks like this: AGNTCY enables interoperability and collaboration in three primary ways:

- Discovery: Agents using the A2A protocol and servers using MCP can be listed and found through AGNTCY's directories. This enables different agents to discover each other and understand their functions.
- Messaging: A2A and MCP communications can be transported over SLIM, AGNTCY's messaging protocol designed for secure and efficient agent interaction.
- Observability: The interactions between these different agents and protocols can be monitored using AGNTCY's observability software development kits (SDKs), which increase transparency and help with debugging complex workflows You can view AGNTCY's code and documentary on GitHub.

BrianFagioli shares a report from NERDS.xyz: Sasha Levin, a respected developer and engineer at Nvidia, has proposed a patch series aimed at formally integrating AI coding assistants into the Linux kernel workflow. The proposal includes two major changes. First, it introduces configuration stubs for popular AI development tools like Claude, GitHub Copilot, Cursor, Codeium, Continue, Windsurf, and Aider. These are symlinked to a centralized documentation file to ensure consistency. Second, and more notably, it lays out official guidelines for how AI-generated contributions should be handled. According to the proposed documentation, AI assistants must identify themselves in commit messages using a Co-developed-by: tag, but they cannot use Signed-off-by:, which legally certifies the commit under the Developer Certificate of Origin. That responsibility remains solely with the human developer.

One example shared in the patch shows a simple fix to a typo in the kernel's OPP documentation. Claude, an AI assistant, corrects "dont" to "don't" and commits the patch with the proper attribution: "Co-developed-by: Claude claude-opus-4-20250514." Levin's patch also creates a new section under Documentation/AI/ where the expectations and limitations of using AI in kernel development are laid out. This includes reminders to follow kernel coding standards, respect the development process, and understand licensing requirements. There are things AI often struggles with.

It was nearly a decade ago when the first RISCV64 port was started for Debian, reports Phoronix. But one of the big features planned for Debian 13.0 (planned for 9 August) is supporting RISC-V as an official CPU architecture. This is the first release where RISC-V 64-bit is officially supported by Debian Linux albeit with limited board support and the Debian RISC-V build process is handicapped by slow hardware.

A Debian RISC-V BoF session was held at this week's DebConf25 conference in France to discuss the state of RISCV64 for Debian Linux. The talk was led by Debian developers Aurelien Jarno and Bo YU... RV64GC is the current target for Debian RISC-V and using UEFI-based booting as the default. Over seventeen thousand source Debian packages are building for RISC-V with Trixie... Those wishing to learn more about this current state of Debian for RISC-V can see the PDF slide deck from DebConf25.