"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."

"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."

An anonymous reader quotes a report from Ars Technica: Researchers have found a never-before-seen piece of macOS malware that combines a series of clever tradecraft to infect Macs with stealthy, custom-developed credential-stealing code. The malware is delivered in two stages. The first is distributed in a disk image that masquerades as Maccy, a clipboard manager for Macs. It's compiled as AppleScript that is notable for the way it delivers the second stage. The malware is named PamStealer because the Rust-written infostealer uses the Pluggable Authentication Modules interface built into macOS to validate the target's login password before sending it to an attacker-controlled server.

[...] PamStealer shows a native password prompt designed to resemble a system authorization request. Text that appears with the prompt says: "Maccy wants to make changes. Enter your password to allow this." As noted earlier, once a target complies, the malware validates it locally through the PAM API. "This check is done entirely through PAM: there is no call out to dscl, security, osascript or any spawned process to verify the password, as many commodity macOS stealers do," [said Jamf, a security firm for macOS users]. "The result is a quieter routine that keeps only a verified password, and one fewer process chain for defenders to detect on."

If the validation fails, PamStealer displays the prompts again until it receives the correct one. Once the target enters the correct password, PamStealer displays a message stating that the file is damaged and can't be installed. This is designed to be a decoy to prevent the target from suspecting anything is amiss. The malware uses tactics to maximize the information it can steal. One tactic is to request the target grant full disk access to the fake Maccy app. It also contains code designed to access ethereum accounts. The various techniques -- particularly the Script Editor lure, a self-contained JXA dropper, a Rust-based second stage, and local validation of credentials through PAM are all noteworthy.

The New York Times tells the story of a 63-year-old retiree who wrote a check for several thousand dollaras to pay her taxes. But she discovered much later that her taxes were never paid because that check had been intercepted and then altered to be payable to someone else: In some cases, thieves may pilfer one or more checks from local mailboxes. Adam Rust, director of financial services for the Consumer Federation of America, said thieves sometimes "fish" for checks at free-standing drop boxes, using long tools with sticky pads on the ends to grab letters. In other cases, more sophisticated criminals may steal large batches of checks, copy them and then sell them on the internet. Often, the purloined checks are chemically altered in what's known as "check washing" to remove the name of the recipient. The thief replaces it with a fraudulent name, and often increases the amount of the check, before cashing or depositing it.
The 63-year-old retiree's bank told her she'd waited too long to recover the funds: Schwab's "security guarantee," outlined on its website , says that "Schwab will cover losses in any of your Schwab accounts due to unauthorized activity." But fine print at the bottom of the page notes that reimbursement "requires your timely reporting of unauthorized activity to Schwab," and that Schwab "will not be liable for additional or increased losses resulting from a failure to report unauthorized activity in a timely manner." It notes that more details are available in account agreements... Notify your bank as soon as possible, said Scott Anchin, senior vice president of strategic initiatives and policy at the independent bankers association. Banks generally allow at least 30 days and sometimes up to 90 days from the time your statement is made available to you to report suspected check fraud, he said.
So how can you avoid check fraud? Adam Rust, director of financial services for the Consumer Federation of America, just suggests that "No one should ever mail a check." If you must write a check, he said, try to deliver it in person or take it inside a post office to mail rather than relying on your own mailbox or public drop boxes. The American Bankers Association recommends using permanent "gel" ink pens when you do write checks to reduce the risk of tampering... And if you don't already, consider using your bank's online bill payment service.
The article notes that even the U.S. federal government "has been moving away from paper checks for things like benefit payments and income tax refunds, saying digital payment methods are more secure."

While the Rust Foundation has a Security Initiative to protect its ecosystem, "the threats have expanded," they announced this week, "and so has the kind of help maintainers need." Much of this comes back to a single shift: Automated tooling (much of it now built on large language models) has gotten good enough to surface real vulnerabilities in open source code quickly and at scale. That is useful, and several large Rust projects have already received and fixed credible issues found this way. The same tooling has also made it trivial to generate vulnerability reports that look plausible and are worthless. Maintainers across the ecosystem are losing real hours sorting these from the reports that matter, and the noise tends to bury the signal.

So, with funding from the Alpha-Omega Project, the Rust Foundation is bringing on a full-time AI Security Engineer in Residence dedicated to the Rust ecosystem. This position is being funded with part of the $12.5M in open source security funding that the Linux Foundation announced in March. The role exists to take pressure off maintainers. The person in this position will use a mix of human-led and AI-assisted methods to proactively review Rust itself and the crates the ecosystem leans on most and help us separate real, exploitable issues from false positives and low-signal noise before anything reaches a maintainer...

This role will run full-time for six months to start, with room to extend depending on what we learn and the funding available. Methods, playbooks, and prompts will be documented so the work doesn't end with the contract. We are grateful that Rust is not embarking on this work in isolation. Several other ecosystems have received parallel Alpha-Omega grants for the same kind of work (e.g., the PHP Foundation and the Drupal Association) and we plan to share tooling, triage practices, and what we learn rather than duplicating work
A statement from Rust's new AI Security Engineer in Residence acknowledges that "One of our next challenges is the wave of bugs discovered by the next generation of AI-powered developer tools."

Epic Games has released Lore, an MIT-licensed version control system written in Rust and designed specifically for "games and entertainment purposes with large file sizes," reports Phoronix. From the report: While there is Git LFS for large file storage with Git, Epic Games has crated Lore as a version control system designed entirely around the large file needs of modern game development as well as multimedia/entertainment purposes. Lore is designed to be fast and efficient for large files including binary files, and be easy-to-use including for 3D artists and more.

The Lore documentation elaborates more on its differences and motivation for development compared to Git: "No existing system was designed for the combination of constraints that large game and entertainment projects require: arbitrary content types, multi-axis scale, multi-tenant safety, and a fully open specification and license. [...] Lore is designed to combine what works in each (Git's content-addressed revision graph and centralized systems): a centralized server-of-record for durability, access control, and conflict resolution; content-addressed storage with fragment-level deduplication that is as effective on a multi-gigabyte binary as on a kilobyte of text; sparse, lazy working copies that materialize only what you need; free branching; and a fully open, publicly versioned specification and MIT license. Normal editing operations -- staging, committing, branching, diffing -- never require a network round trip." You can learn more at Lore.org. All the code is available on GitHub.

Longtime Slashdot reader Dotnaught shares a report from The Register: For the past 90 days, Microsoft has been quietly patching a firmware flaw in Surface devices that allowed the hardware to be bricked with a single packet, though only for those who have disabled Secure Core and Secure Boot. And the company's Copilot AI software inadvertently helped identify the faulty firmware.

According to Jack Darcy, a security researcher based in Australia, his instance of Microsoft Copilot stumbled across the bug after being asked to adjust the screen backlighting on a Surface device. The Copilot-conjured Python script ended up rendering the researcher's laptop inoperable by overwriting the embedded controller firmware. "Copilot autonomously created and executed four progressively aggressive Python scripts during a probe for backlight control values that sent raw SSAM ioctl commands (SSAM_CDEV_REQUEST = 0xC028A501) directly to the SAM microcontroller through the SAM software path," Darcy explained to The Register.

[...] "We appreciate the work of Jack Darcy and The Register for reporting this issue under a coordinated vulnerability disclosure," a Microsoft spokesperson said in a statement. "Our investigation found that a deprecated UEFI interface could trigger a boot loop on some devices. To trigger this loop, the user must have administrator privileges and have already disabled the Secure Boot security feature. We have released updates to address the issue for most impacted devices."

That means managed devices are not at risk. But those using Linux, or Windows users who have disabled Secure Core and Secure Boot for gaming, or who use custom Windows drivers, or who have USB boot enabled, may still be vulnerable if their systems haven't received the update. We're uncertain about the range of Surface devices affected. Our source said it appears to be all of them (Surface Laptops 3-6, Surface Book 1-3) except for Surface Go models. ARM variants, however, have not been tested. The report notes that Microsoft is planning to move the Surface stack to a more secure architecture based on Rust code.

"Our most recent Surface for Business hardware features a major architectural shift in terms of improved reliability and security that spans our embedded controller, UEFI, but also some of our drivers," said David Abzarian, chief architect for Microsoft Surface. "We're investing in the most secure foundation for a PC by building our embedded controller firmware from the ground up in Rust (as part of leveraging and contributing to the Open Device Partnership (ODP)) in addition to a rewrite of the UEFI DXE Core in Rust; these projects are known as Secure EC and Project Patina respectively."

"We're also not only shipping some of our drivers written in Rust, but also helping co-develop the framework Windows Drivers in Rust (WDR) to help enable a broad set of partners in the Windows ecosystem to capitalize on these benefits. I will also note that all of these efforts are open-source promoting one of our key security principles around transparency."

The Ladybird browser isn't opposed to AI coding tools, but it's just brought a new change to their code-contributing policies.

February 23: "Ladybird adopts Rust, with help from AI." Our first target was LibJS , Ladybirdâ(TM)s JavaScript engine... I used Claude Code and Codex for the translation. This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go... The requirement from the start was byte-for-byte identical output from both pipelines. The result was about 25,000 lines of Rust, and the entire port took about two weeks. The same work would have taken me multiple months to do by hand.
June 5 (Friday): We will no longer accept public pull requests... A pull request no longer tells us as much as it used to about the person submitting it. A substantial patch used to imply substantial effort, and that effort was a reasonable proxy for good faith. That assumption no longer holds....

We have already seen patient, well-resourced campaigns in open source to earn maintainer trust and abuse it. What has changed is how much faster and cheaper it has become to produce work that looks like a serious contribution... Whether code was typed by hand is beside the point. What matters is who is responsible for it once it enters the browser. Ladybird is becoming a browser for real users. The people introducing changes to it must be the people who decide those changes belong in the project, and who will answer for the consequences.

As part of this change, we will close all currently open public pull requests. We are grateful for the work people put into them, but keeping the existing queue open would keep that contribution path open in practice. There is no perfect time to make this change, so we are making it now. Going forward, pull requests will only be available to project maintainers. There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks...

Outside involvement still matters: clear bug reports, reductions, website testing, standards discussion, design discussion, security reports, and technical feedback all help move the project forward. This is the right change for Ladybird now. We are preparing to ship a browser to real users, and our development process has to match that responsibility.

A new npm supply-chain attack has infected 36 packages with Rust-based infostealer malware called IronWorm. According to BleepingComputer, the malware "targets 86 environment variables (key-value pairs) and 20 credential files that may contain OpenAI, AWS, Anthropic, and npm credentials, vault configuration files, SSH keys, and Exodus cryptocurrency wallet files." From the report: According to researchers at supply-chain and devops company JFrog, IronWorm is written in Rust, hides behind an eBPF kernel rootkit, and communicates with the operator over the Tor network. The Rust-based malware self-propagates by using stolen credentials for publishing on npm; this includes secrets associated with npm's Trusted Publishing workflow. Once it compromises a developer or CI environment, it can publish trojanized versions of packages owned by the victim, which then infect additional developers and CI systems.

This behavior is conceptually similar to Shai Hulud, which had its code published on GitHub recently. Although JFrog researchers did not find a clear connection between IronWorm and Shai Hulud, they observed the same commit names in both supply-chain attacks. This opens the possibility that the new malware is an evolution of TeamPCP's payload, since IronWorm appears to be "a custom, carefully built implant from an operation with its own infrastructure."

[...] The company provides a list of all impacted package names and their versions in the report and recommends that developers upgrade to fixed releases, rotate their keys, and enable two-factor authentication (2FA) for all accounts. At the same time, Endor Labs and StepSecurity have spotted a very similar but distinct attack involving a JavaScript-based malware named binding.gyp, performing registry poisoning and GitHub Actions infection, unfolding during the same time-frame.

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."

Red Hat has released RHEL 10.2 and 9.8 with new AI-assisted command-line tools. The releases also add updated developer toolchains such as Go 1.26, LLVM 21, Rust 1.92, Python 3.14, and PHP 8.4. Phoronix reports: Red Hat Enterprise Linux has introduced the goose command for power users. Goose is an optional CLI AI assistance with model context protocol (MCP) integration. There is also improved visual output via color output enhancements. As for their rationale with the new AI integration: "The business value: Faster problem resolution, and a quicker path for new administrators to become proficient. This translates into higher developer productivity and accelerated project timelines."

Are statistical programmers coalescing around a handful of popular languages? That's the question asked by the CEO of software assessment site TIOBE, which every month estimates the popularity of programming languages based on their frequency in search results: This month, the programming language R matched its all-time high by reaching position #8 in the TIOBE index once again. This is not a coincidence. The statistical programming language market is clearly undergoing a major consolidation. The biggest winners are Python and R, while many long-established alternatives continue to lose momentum. The era in which the statistical computing landscape was fragmented across many niche languages and platforms appears to be coming to an end.

Several established players are steadily declining:

— MATLAB is close to dropping out of the TIOBE top 20.

— SAS is about to leave the top 30 for the first time since the TIOBE index began.

— Wolfram/Mathematica remains well below its historical peak and is losing further ground.

— SPSS dropped out of the top 100 last month....


Elsewhere in the index, Java and C++ swapped positions this month. Java gained momentum following the successful release of Java 26. Another notable riser is Zig, which is approaching the TIOBE top 30 for the first time. Zig's growing popularity appears to be driven by its rare combination of low-level performance, straightforward tooling, and relative ease of use compared to traditional systems programming languages.
Their estimate for the most popular programming languages in May:

1. Python
2. C
3. Java
4. C++
5. C#
6. JavaScript
7. Visual Basic
8. R
9. SQL
10. Delphi/Object Pascal

The five next most popular languages on their rankings are Fortran, Scratch, Perl, PHP, and then Rust at #15. Rust is up for positions from May of 2025 — while Go has dropped to #16, seven ranks lower than its May 2025 position of #7.

Under the nonprofit Linux Foundation, "a new Sustaining Package Registries Working Group will seek to identify concrete funding, governance, and security practices," reports ZDNet, "to keep code flowing as download counts grow.... Because software builds, continuous integration pipelines, and AI systems hammer registries at machine speed rather than human speed, the sites can't keep up.

"That growth has brought a surge in bot traffic, automated publishing, security reports, and outright abuse, exposing what the working group bluntly calls a 'sustainability gap'." Sonatype CTO Brian Fox, who oversees the Maven Central Java registry, estimates open-source registries saw 10 trillion downloads in 2025. And "The same pattern is appearing across ecosystems. More machine traffic. More automation. More scanning. More expectations around uptime, integrity, provenance, and policy enforcement. More cost. More support burden. More dependency on infrastructure that the industry still talks about as though it runs on goodwill and spare time."

ZDNet reports that "To tackle that, Sonatype has teamed up with the Linux Foundation and other package registry leaders, including Alpha-Omega, Eclipse Foundation (OpenVSX), OpenJS Foundation, OpenSSF, Packagist, Python Software Foundation, Ruby Central (RubyGems), and the Rust Foundation (Crates)." The idea is to give operators a neutral forum to discuss money, governance, and shared operational burdens openly. Once that's dealt with, they'll coordinate how to explain those realities back to companies and organizations that have long assumed registries are "free." No, they're not. They never were. As the Linux Foundation pointed out, "Registries today run primarily on two things: (1) infrastructure donations and credits; and (2) heroic efforts from small paid teams (themselves funded by donations and grants) and unpaid volunteers that operate and maintain registry services. The bulk of donations and grants comes from a small set of donors and doesn't scale with demands on the registry."

The working group is explicitly positioned as a venue where registry leaders and ecosystem stakeholders can align on "practical, community-minded" ways to sustain that infrastructure, rather than each operator improvising its own survival plan in isolation.
ZDNet says the group will also coordinate security practices and information, and craft frameworks "that make it politically and legally possible to introduce sustainable funding models without fracturing communities." And they will also "align messaging and educational content so developers, companies, and policymakers finally understand what it costs to run these services."

An anonymous reader quotes a report from Ars Technica: Last month, Anthropic made a big deal about the supposedly outsize cybersecurity threat represented by its Mythos Preview model, leading the company to restrict the initial release to "critical industry partners." But new research from the UK's AI Security Institute (AISI) suggests that OpenAI's GPT-5.5, which launched publicly last week, reached "a similar level of performance on our cyber evaluations" as Mythos Preview, which the group evaluated last month.

Since 2023, the AISI has run a variety of frontier AI models through 95 different Capture the Flag challenges designed to test capabilities on cybersecurity tasks, such as reverse engineering, web exploitation, and cryptography. On the highest-level "Expert" tasks, GPT-5.5 passed an average of 71.4 percent, slightly higher than the 68.6 percent achieved by Mythos Preview (though within the margin of error). In one particularly difficult task that involved building a disassembler to decode a Rust binary, AISI notes that "GPT-5.5 solved the challenge in 10 minutes and 22 seconds with no human assistance at a cost of $1.73" in API calls.

GPT-5.5 also matched Mythos Preview in its progress on "The Last Ones" (TLO), an AISI test range set up to simulate a 32-step data extraction attack on a corporate network. GPT-5.5 succeeded in 3 of 10 attempts on TLO, compared to 2 of 10 for Mythos Preview -- no previous model had ever succeeded at the test even once. But GPT-5.5 still fails at AISI's more difficult "Cooling Tower" simulation of an attempted disruption of the control software for a power plant, as every previously tested AI model also has. The new results for GPT-5.5 suggest that, when it comes to cybersecurity risk, Mythos Preview was likely not "a breakthrough specific to one model" but rather "a byproduct of more general improvements in long-horizon autonomy, reasoning, and coding," AISI writes.

"The new Linux kernel was released and it's kind of a big deal," writes longtime Slashdot reader rexx mainframe. "Here is what you can expect." Linuxiac reports: A key update in Linux 7.0 is the removal of the experimental label from Rust support. That (of course) does not make Rust a dominant language in kernel development, but it is still an important step in its gradual integration into the project. Another notable security-related change is the addition of ML-DSA post-quantum signatures for kernel module authentication, while support for SHA-1-based module-signing schemes has been removed.

The kernel now includes BPF-based filtering for io_uring operations, providing administrators with improved control in restricted environments. Additionally, BTF type lookups are now faster due to binary search. At the same time, this release continues ongoing cleanup in the kernel's lower layers. The removal of linuxrc initrd code advances the transition to initramfs as the sole early-userspace boot mechanism.

Linux 7.0 also introduces NULLFS, an immutable and empty root filesystem designed for systems that mount the real root later. Plus, preemption handling is now simpler on most architectures, with further improvements to restartable sequences, workqueues, RCU internals, slab allocation, and type-based hardening. Filesystems and storage receive several updates as well. Non-blocking timestamp updates now function correctly, and filesystems must explicitly opt in to leases rather than receiving them by default. Phoronix has compiled a list of the many exciting changes.

Linus Torvalds himself announced the release, which can be downloaded directly from his git tree or from the kernel.org website.

Linux 7.0 has a major new version number but it's "largely a numbering reset [...], not a sign of some unusually disruptive release," notes Linuxiac.

"Rust's rise shows signs of slowing," argues the CEO of TIOBE.

Back in 2020 Rust first entered the top 20 of his "TIOBE Index," which ranks programming language popularity using search engine results. Rust "was widely expected to break into the top 10," he remembers today. But it never happened, and "That was nearly six years ago...." Since then, Rust has steadily improved its ranking, even reaching its highest position ever (#13) at the beginning of this year. However, just three months later, it has dropped back to position #16. This suggests that Rust's adoption rate may be plateauing.

One possible explanation is that, despite its ability to produce highly efficient and safe code, Rust remains difficult to learn for non-expert programmers. While specialists in performance-critical domains are willing to invest in mastering the language, broader mainstream adoption appears more challenging. As a result, Rust's growth in popularity seems to be leveling off, and a top 10 position now appears more distant than before.
Or, could Rust's sudden drop in the rankings just reflect flaws in TIOBE's ranking system? In January GitHub's senior director for developer advocacy argued AI was pushing developers toward typed languages, since types "catch the exact class of surprises that AI-generated code can sometimes introduce... A 2025 academic study found that a whopping 94% of LLM-generated compilation errors were type-check failures." And last month Forbes even described Rust as "the the safety harness for vibe coding."

A year ago Rust was ranked #18 on TIOBE's index — so it still rose by two positions over the last 12 months, hitting that all-time high in January. Could the rankings just be fluctuating due to anomalous variations in each month's search engine results? Since January Java has fallen to the #4 spot, overtaken by C++ (which moved up one rank to take Java's place in the #3 position).

Here's TIOBE's current estimate for the 10 most popularity programming languages:

1. Python
2. C
3. C++
4. Java
5. C#
6. JavaScript
7. Visual Basic
8. SQL
9. R
10. Delphi/Object Pascal

TIOBE estimates that the next five most popular programming languages are Scratch, Perl, Fortran, PHP, and Go.

BrianFagioli writes: Little Snitch, the well known macOS tool that shows which applications are connecting to the internet, is now being developed for Linux. The developer says the project started after experimenting with Linux and realizing how strange it felt not knowing what connections the system was making. Existing tools like OpenSnitch and various command line utilities exist, but none provided the same simple experience of seeing which process is connecting where and blocking it with a click. The Linux version uses eBPF for kernel level traffic interception, with core components written in Rust and a web based interface that can even monitor remote Linux servers.

During testing on Ubuntu, the developer noticed the system was relatively quiet on the network. Over the course of a week, only nine system processes made internet connections. By comparison, macOS reportedly showed more than one hundred processes communicating externally. Applications behave similarly across platforms though. Launching Firefox immediately triggered telemetry and advertising related connections, while LibreOffice made no network connections at all during testing. The early release is meant primarily as a transparency tool to show what software is doing on the network rather than a hardened security firewall.

BrianFagioli writes: Canonical has joined the Rust Foundation as a Gold Member, signaling a deeper investment in the Rust programming language and its role in modern infrastructure. The company already maintains an up-to-date Rust toolchain for Ubuntu and has begun integrating Rust into parts of its stack, citing memory safety and reliability as key drivers. By joining at a higher tier, Canonical is not just adopting Rust but also stepping closer to its governance and long-term direction.

The move also highlights ongoing tensions in Rust's ecosystem. While Rust can reduce entire classes of bugs, it often depends heavily on external crates, which can introduce complexity and auditing challenges, especially in enterprise environments. Canonical appears aware of that tradeoff and is positioning itself to influence how the ecosystem evolves, as Rust continues to gain traction across Linux and beyond. "As the publisher of Ubuntu, we understand the critical role systems software plays in modern infrastructure, and we see Rust as one of the most important tools for building it securely and reliably. Joining the Rust Foundation at the Gold level allows us to engage more directly in language and ecosystem governance, while continuing to improve the developer experience for Rust on Ubuntu," said Jon Seager, VP Engineering at Canonical. "Of particular interest to Canonical is the security story behind the Rust package registry, crates.io, and minimizing the number of potentially unknown dependencies required to implement core concerns such as async support, HTTP handling, and cryptography -- especially in regulated environments."

Interesting Engineering reports: US tech giant Google announced on Tuesday that it will build a new data center in Pine Island, Minnesota. The new facility will be powered by 1.9 gigawatts (GW) of clean energy from wind and solar, coupled with a 300-megawatt battery, claimed to be the 'world's largest', with a 30-gigawatt-hour (GWh) capacity and 100-hour duration... The planned battery would dwarf a 19 GW lithium-ion project in the UAE...

Form Energy's batteries work very differently from most large batteries today. Instead of using lithium like the batteries in electric cars, they store electricity by making iron rust and then reversing the rusting process to release the energy when needed... Form's iron-air batteries are heavier and less efficient than their counterparts; they can only return about 50% to 70% of the energy used to charge them, while lithium-ion batteries return more than 90%. However, Form's batteries have one distinct advantage. They are cheaper than lithium-ion batteries, costing about $20 per kilowatt-hour of storage, which is almost three times as cheap... It will store 150 MWh of electricity and can supply to the grid for up to 100 hours, delivering about 1.5 MW at peak output.
Thanks to long-time Slashdot reader schwit1 for sharing the article.

Google and Microsoft contributed $5 million to launch Alpha-Omega in 2022 — a Linux Foundation project to help secure the open source supply chain. But its co-founder Michael Winser warns that open source registries are in financial peril, reports The Register, since they're still relying on non-continuous funding from grants and donations.

And it's not just because bandwidth is expensive, he said at this year's FOSDEM. "The problem is they don't have enough money to spend on the very security features that we all desperately need..." In a follow-up LinkedIn exchange after this article had posted, Winser estimated it could cost $5 million to $8 million a year to run a major registry the size of Crates.io, which gets about 125 billion downloads a year. And this number wouldn't include any substantial bandwidth and infrastructure donations (Like Fastly's for Crates.io). Adding to that bill is the growing cost of identifying malware, the proliferation of which has been amplified through the use of AI and scripts. These repositories have detected 845,000 malware packages from 2019 to January 2025 (the vast majority of those nasty packages came to npm)...

In some cases benevolent parties can cover [bandwidth] bills: Python's PyPI registry bandwidth needs for shipping copies of its 700,000+ packages (amounting to 747PB annually at a sustained rate of 189 Gbps) are underwritten by Fastly, for instance. Otherwise, the project would have to pony up about $1.8 million a month. Yet the costs Winser was most concerned about are not bandwidth or hosting; they are the security features needed to ensure the integrity of containers and packages. Alpha-Omega underwrites a "distressingly" large amount of security work around registries, he said. It's distressing because if Alpha-Omega itself were to miss a funding round, a lot of registries would be screwed. Alpha-Omega's recipients include the Python Software Foundation, Rust Foundation, Eclipse Foundation, OpenJS Foundation for Node.js and jQuery, and Ruby Central.

Donations and memberships certainly help defray costs. Volunteers do a lot of what otherwise would be very expensive work. And there are grants about...Winser did not offer a solution, though he suggested the key is to convince the corporate bean counters to consider paid registries as "a normal cost of doing business and have it show up in their opex as opposed to their [open source program office] donation budget."
The dilemma was summed up succinctly by the anonymous Slashdot reader who submitted this story.

"Free beer is great. Securing the keg costs money!"