"I have not pulled this, I'm annoyed by having to even look at this, and if you actually expect me to pull this I want a real explanation and not a useless link," Linus Torvalds posted Friday on the Linux kernel mailing list.

Phoronix explains: It's become a common occurrence seeing "Link: " tags within Git commits for the Linux kernel that point to the latest Linux kernel mailing list patches of the same patch... Linus Torvalds has had enough and will be more strict against accepting pull requests that have link tags of no value. He commented yesterday on a block pull request that he pulled and then backed out of:

"And dammit, this commit has that promising 'Link:' argument that I hoped would explain why this pointless commit exists, but AS ALWAYS that link only wasted my time by pointing to the same damn information that was already there. I was hoping that it would point to some oops report or something that would explain why my initial reaction was wrong.

"Stop this garbage already. Stop adding pointless Link arguments that waste people's time. Add the link if it has *ADDITIONAL* information....

"Yes, I'm grumpy. I feel like my main job — really my only job — is to try to make sense of pull requests, and that's why I absolutely detest these things that are automatically added and only make my job harder."
A longer discussion ensued...

• Torvalds: [A] "perfect" model might be to actually have some kind of automation of "unless there was actual discussion about it". But I feel such a model might be much too complicated, unless somebody *wants* to explore using AI because their job description says "Look for actual useful AI uses". In today's tech world, I assume such job descriptions do exist. Sigh...

• Torvalds: I do think it makes sense for patch series that (a) are more than a small handful of patches and (b) have some real "story" to them (ie a cover letter that actually explains some higher-level issues)...

Torvalds also had two responses to a poster who'd said "IMHO it's better to have a Link and it _potentially_ being useful than not to have it and then need to search around for it."

• Torvalds: No. Really. The issue is "potentially — but very likely not — useful" vs "I HIT THIS TEN+ TIMES EVERY SINGLE F%^& RELEASE".
  
  There is just no comparison. I have literally *never* found the original submission email to be useful, and I'm tired of the "potentially useful" argument that has nothing to back it up with. It's literally magical thinking of "in some alternate universe, pigs can fly, and that link might be useful"

• Torvalds: And just to clarify: the hurt is real. It's not just the disappointment. It's the wasted effort of following a link and having to then realize that there's nothing useful there. Those links *literally* double the effort for me when I try to be careful about patches...
  
  The cost is real. The cost is something I've complained about before... Yes, it's literally free to you to add this cost. No, *YOU* don't see the cost, and you think it is helpful. It's not. It's the opposite of helpful. So I want commit messages to be relevant and explain what is going on, and I want them to NOT WASTE MY TIME.
  
  And I also don't want to ignore links that are actually *useful* and give background information. Is that really too much to ask for?

Torvalds points out he's brought this up four times before — once in 2022.

• Torvalds: I'm a bit frustrated, exactly because this _has_ been going on for years. It's not a new peeve.
  
  And I don't think we have a good central place for that kind of "don't do this". Yes, there's the maintainer summit, but that's a pretty limited set of people. I guess I could mention it in my release notes, but I don't know who actually reads those either.. So I end up just complaining when I see it.

Mozilla announced today that they will end 32-bit Linux support for Firefox in 2026, with version 144 being the last release and ESR 140 as the fallback option. Phoronix reports: Firefox has continued providing 32-bit Linux binaries even with most other web browsers and operating systems going all-in on x86_64 support. But given that 32-bit Linux support is waning by distributions and the vast majority of distributions aren't even shipping i686 install images anymore, they will be removing 32-bit Linux builds in 2026.

Linus Torvalds updated the kernel's MAINTAINERS file to mark Bcachefs as "externally maintained," signaling he won't accept new Bcachefs pull requests for now. "MAINTAINERS: mark bcachefs externally maintained," wrote Torvalds with the patch. "As per many long discussion threads, public and private."

"The Bcachefs code is still present in the mainline Linux kernel likely to prevent users from having any immediate fall-out in Bcachefs file-systems they may already be using, but it doesn't look like Linus Torvalds will be honoring any new Bcachefs pull requests in the near future," adds Phoronix's Michael Larabel.

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.