A maintainer of Debian's Advanced Package Tool (APT) "has announced plans to introduce hard Rust dependencies into APT starting May 2026," reports the blog It's FOSS. The integration targets critical areas like parsing .deb, .ar, and tar files plus HTTP signature verification using Sequoia. [APT maintainer Julian Andres Klode] said these components "would strongly benefit from memory safe languages and a stronger approach to unit testing."

He also gave a firm message to maintainers of Debian ports: "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."

The reasoning is straightforward. Debian wants to move forward with modern tools rather than being held back by legacy architecture... Debian ports running on CPU architectures without Rust compiler support have six months to add proper toolchains. If they can't meet this deadline, those ports will need to be discontinued. As a result, some obscure or legacy platforms may lose official support. For most users on mainstream architectures like x86_64 and ARM, nothing changes. Your APT will simply become more secure and reliable under the hood.
It's FOSS argues that "If done right, this could significantly strengthen APT's security and code quality."

And the blog Linuxiac also supports the move. "By embedding Rust into APT, the distro joins a growing number of major open-source projects, such as the Linux kernel, Firefox, and systemd, that are gradually adopting Rust. And if I had to guess, I'd say this is just one of the first steps toward even deeper Rust integration in this legendary distribution, which is a good thing."

BrianFagioli writes: Google has released Magika 1.0, a stable version of its AI-based file type detection tool, and rebuilt the entire engine in Rust for speed and memory safety. The system now recognizes more than 200 file types, up from about 100, and is better at distinguishing look-alike formats such as JSON vs JSONL, TSV vs CSV, C vs C++, and JavaScript vs TypeScript. The team used a 3TB training dataset and even relied on Gemini to generate synthetic samples for rare file types, allowing Magika to handle formats that don't have large, publicly available corpora. The tool supports Python and TypeScript integrations and offers a native Rust command-line client.

Under the hood, Magika uses ONNX Runtime for inference and Tokio for parallel processing, allowing it to scan around 1,000 files per second on a modern laptop core and scale further with more CPU cores. Google says this makes Magika suitable for security workflows, automated analysis pipelines, and general developer tooling. Installation is a single curl or PowerShell command, and the project remains fully open source. The project is available on GitHub and documentation can be found here.

"Ubuntu's decision to switch to Rust-based coreutils in 25.10 hasn't been the smoothest ride," writes the blog OMG Ubuntu, "as the latest — albeit now resolved — bug underscores." [Coreutils] are used by a number of processes, apps and scripts, including Ubuntu's own unattended-upgrades process, which automatically checks for new software updates. Alas, the Rust-based version of date had a bug which meant Ubuntu 25.10 desktops, servers, cloud and container images were not able to automatically check for updates when configured. Unattended-upgrades hooks into the date utility to check the timestamp of a reference file of when an update check was last run and, past a certain date, checks again. But date was incorrectly showing the current date, always.

A fix has been issued so only Ubuntu 25.10 installs withrust-coreutils 0.2.2-0ubuntu2 (or earlier) are affected.

"We've spent the last year rebuilding major components of our system," Cloudflare announced this week, "and we've just slashed the latency of traffic passing through our network for millions of our customers," (There's a 10ms cut in the median time to respond, plus a 25% performance boost as measured by CDN performance tests.) They replaced a 15-year-old system named FL (where they run security and performance features), and "At the same time, we've made our system more secure, and we've reduced the time it takes for us to build and release new products."

And yes, Rust was involved: We write a lot of Rust, and we've gotten pretty good at it... We built FL2 in Rust, on Oxy [Cloudflare's Rust-based next generation proxy framework], and built a strict module framework to structure all the logic in FL2... Built in Rust, [Oxy] eliminates entire classes of bugs that plagued our Nginx/LuaJIT-based FL1, like memory safety issues and data races, while delivering C-level performance. At Cloudflare's scale, those guarantees aren't nice-to-haves, they're essential. Every microsecond saved per request translates into tangible improvements in user experience, and every crash or edge case avoided keeps the Internet running smoothly. Rust's strict compile-time guarantees also pair perfectly with FL2's modular architecture, where we enforce clear contracts between product modules and their inputs and outputs...

It's a big enough distraction from shipping products to customers to rebuild product logic in Rust. Asking all our teams to maintain two versions of their product logic, and reimplement every change a second time until we finished our migration was too much. So, we implemented a layer in our old NGINX and OpenResty based FL which allowed the new modules to be run. Instead of maintaining a parallel implementation, teams could implement their logic in Rust, and replace their old Lua logic with that, without waiting for the full replacement of the old system.
Over 100 engineers worked on FL2 — and there was extensive testing, plus a fallback-to-FL1 procedure. But "We started running customer traffic through FL2 early in 2025, and have been progressively increasing the amount of traffic served throughout the year...." As we described at the start of this post, FL2 is substantially faster than FL1. The biggest reason for this is simply that FL2 performs less work [thanks to filters controlling whether modules need to run]... Another huge reason for better performance is that FL2 is a single codebase, implemented in a performance focussed language. In comparison, FL1 was based on NGINX (which is written in C), combined with LuaJIT (Lua, and C interface layers), and also contained plenty of Rust modules. In FL1, we spent a lot of time and memory converting data from the representation needed by one language, to the representation needed by another. As a result, our internal measures show that FL2 uses less than half the CPU of FL1, and much less than half the memory. That's a huge bonus — we can spend the CPU on delivering more and more features for our customers!

Using our own tools and independent benchmarks like CDNPerf, we measured the impact of FL2 as we rolled it out across the network. The results are clear: websites are responding 10 ms faster at the median, a 25% performance boost. FL2 is also more secure by design than FL1. No software system is perfect, but the Rust language brings us huge benefits over LuaJIT. Rust has strong compile-time memory checks and a type system that avoids large classes of errors. Combine that with our rigid module system, and we can make most changes with high confidence...

We have long followed a policy that any unexplained crash of our systems needs to be investigated as a high priority. We won't be relaxing that policy, though the main cause of novel crashes in FL2 so far has been due to hardware failure. The massively reduced rates of such crashes will give us time to do a good job of such investigations. We're spending the rest of 2025 completing the migration from FL1 to FL2, and will turn off FL1 in early 2026. We're already seeing the benefits in terms of customer performance and speed of development, and we're looking forward to giving these to all our customers.

After that, when everything is modular, in Rust and tested and scaled, we can really start to optimize...!
Thanks to long-time Slashdot reader Beeftopia for sharing the article.

Ubuntu "is adopting the memory-safe Rust language," reports ZDNet, citing remarks at this year's Ubuntu Summit from Jon Seager, Canonical's VP of engineering for Ubuntu: . Seager said the engineering team is focused on replacing key system components with Rust-based alternatives to enhance safety and resilience, starting with Ubuntu 25.10. He stressed that resilience and memory safety, not just performance, are the principal drivers: "It's the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me". This move is echoed in Ubuntu's adoption of sudo-rs, the Rust implementation of sudo, with fallback and opt-out mechanisms for users who want to use the old-school sudo command.

In addition to sudo-rs, Ubuntu 26.04 will use the Rust-based uutils/coreutils for Linux's default core utilities. This setup includes ls, cp, mv, and dozens of other basic Unix command-line tools. This Rust reimplementation aims for functional parity with GNU coreutils, with improved safety and maintainability.

On the desktop front, Ubuntu 26.04 will also bring seamless TPM-backed full disk encryption. If this approach reminds you of Windows BitLocker or MacOS FileVault, it should. That's the idea.
In other news, Canonical CEO Mark Shuttleworth said "I'm a believer in the potential of Linux to deliver a desktop that could have wider and universal appeal." (Although he also thinks "the open-source community needs to understand that building desktops for people who aren't engineers is different. We need to understand that the 'simple and just works' is also really important.")

Shuttleworth answered questions from Slashdot's readers in 2005 and 2012.

prisoninmate shares a report from 9to5Linux: Dubbed Questing Quokka, Ubuntu 25.10 is powered by the latest and greatest Linux 6.17 kernel series for top-notch hardware support and ships with the latest GNOME 49 desktop environment, defaulting to a Wayland-only session for the Ubuntu Desktop flavor, meaning there's no other session to choose from the login screen. Ubuntu Desktop also ships with two new apps, namely GNOME's Loupe instead of Eye of GNOME as the default image viewer, as well as Ptyxis instead of GNOME Terminal as the default terminal emulator. Also, there's a new update notification that will be shown with options to open Software Updater or install updates directly.'

Other highlights of Ubuntu 25.10 include sudo-rs as the default implementation of sudo, Dracut as the default initramfs-tools, Chrony as the default NTP (Network Time Protocol) client, Rust Coreutils as the default implementation of GNU Core Utilities, and TPM-backed FDE (Full Disk Encryption) recovery key management. Moreover, Ubuntu 25.10 adds NVIDIA Dynamic Boost support and enables suspend-resume support in the proprietary NVIDIA graphics driver to prevent corruption and freezes when waking an NVIDIA desktop. For Intel users, Ubuntu 25.10 introduces support for new Intel integrated and discrete GPUs. Ubuntu 25.10 is available for download here.

The Moon is rusting -- and it's Earth's fault. Nature: Scientists have found that oxygen particles blown from Earth to the Moon can turn lunar minerals into hematite, also known as rust. The discovery adds to researchers' growing understanding of the deep interconnection between Earth and the Moon -- and shows how the Moon keeps a geological record of those interactions, says Ziliang Jin, a planetary scientist at Macau University of Science and Technology in China. He and his colleagues reported their findings earlier this month in Geophysical Research Letters.

Most of the time, both Earth and the Moon are bathed in a stream of charged particles emanating from the Sun. But for around five days each month, Earth passes between the Sun and the Moon, blocking most of the flood of solar particles. During that time, the Moon is exposed mainly to particles that had been part of Earth's atmosphere before blowing into space -- a phenomenon known as Earth wind. That wind contains ions of various elements, including hydrogen, oxygen and nitrogen. When those charged particles hit the Moon, they can implant themselves into the upper layers of lunar soil and trigger chemical reactions.

Long-time Slashdot reader robinsrowe shared this report from the Register: The C++ standards committee abandoned a detailed proposal to create a rigorously safe subset of the language, according to the proposal's co-author, despite continuing anxiety about memory safety. "The Safety and Security working group voted to prioritize Profiles over Safe C++. Ask the Profiles people for an update. Safe C++ is not being continued," Sean Baxter, author of the cutting-edge Circle C++ compiler, commented in June this year. The topic came up as developers like Simone Bellavia noted the anniversary of the proposal and discovered a decision had been made on Safe C++.

One year ago, Baxter told The Reg that the project would enable C++ developers to get the memory safety of Rust, but without having to learn a new language. "Safe C++ prevents users from writing unsound code," he said. "This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety." Safe C++ would enable incremental migration of code, since it only applies to code in the safe context. Existing unsafe code would run as before.

Even the matter of whether the proposal has been abandoned is not clear-cut. Erich Keane, C++ committee member and co-chair of the C++ Evolution Working Group (EWG), said that Baxter's proposal "got a vote of encouragement where roughly 1/2 (20/45) of the people encouraged Sean's paper, and 30/45 encouraged work on profiles (with 6 neutral)... Sean is completely welcome to continue the effort, and many in the committee would love to see him make further effort on standardizing it."

In response, Baxter said: "The Rust safety model is unpopular with the committee. Further work on my end won't change that. Profiles won the argument." He added that the language evolution principles adopted by the EWG include the statement that "we should avoid requiring a safe or pure function annotation that has the semantics that a safe or pure function can only call other safe or pure functions." This, he said, is an "irreconcilable design disagreement...."

TIOBE attempts to calculate programming language popularity using the number of skilled engineers, courses, and third-party vendors.

And the eight most popular languages in September's rankings haven't changed since last month:

1. Python
2. C++
3. C
4. Java
5. C#
6. JavaScript
7. Visual Basic
8. Go

But by TIOBE's ranking, Perl is still the #10 most-popular programming in September (dropping from #9 in August). "One year ago Perl was at position 27 and now it suddenly pops up at position 10 again," marvels TIOBE CEO Paul Jansen. The technical reason why Perl is rated this high is because of its huge number of books on Amazon. It has 4 times more books listed than for instance PHP, or 7 times more books than Rust. The underlying "real" reason for Perl's increase of popularity is unknown to me. The only possibility I can think of is that Perl 5 is now gradually considered to become the real Perl... Perl 6/Raku is at position 129 of the TIOBE index, thus playing no role at all in the programming world. Perl 5 on the other hand is releasing more often recently, thus gaining attention.
An article at the i-Programmer blog thinks Perl's resurgence could be from its text processing capabilities: Even in this era of AI, everything is still governed by text formats; text is still the King. XML, JSON calling APIs, YAML, Markdown, Log files..That means that there's still need to process it, transform it, clean it, extract from it. Perl with its first-class-citizen regular expressions, the wealth of text manipulation libraries up on CPAN and its full Unicode support of all the latest standards, was and is still the best. Simply there's no other that can match Perl's text processing capabilities.
They also cite Perl's backing by the open source community, and its "getting a 'proper' OOP model in the last couple of years... People just don't know what Perl is capable of and instead prefer to be victims of FOMO ephemeral trends, chasing behind the new and shiny."

Perl creator Larry Wall answered questions from Slashdot's readers in 2016. So I'd be curious from Slashdot's readers about Perl today. (Share your experiences in the comments if you're still using Perl -- or Raku...)

Perl's drop to #9 means Delphi/Object Pascal rises up one rank, growing from 1.82% in August to 2.26% in September to claim September's #9 spot. "At number 11 and 1.86%, SQL is quite close to entering the top 10 again," notes TechRepublic. (SQL fell to #12 in June, which the site speculated was due to "the increased use of NoSQL databases for AI applications.")

But TechRepublic adds that the #1 most popular programming language (according to TIOBE) is still Python: Perl sits at 2.03% in TIOBE's proprietary ranking system in September, up from 0.64% in January. Last year, Perl held the 27th position... Python's unstoppable rise dipped slightly from 26.14% in August to 25.98% in September. Python is still well ahead of every other language on the index.

Announced this week at RustConf 2025 in Seattle, the new Rust Innovation Lab will offer open source projects "the opportunity to receive fiscal sponsorship from the Rust Foundation, including governance, legal, networking, marketing, and administrative support."

And their first project will be the TLS library Rustls (for cryptographic security), which they say "demonstrates Rust's ability to deliver both security and performance in one of the most sensitive areas of modern software infrastructure." Choosing Rustls "underscores the lab's focus on infrastructure-critical tools, where reliability is paramount," argues explains WebProNews. But "Looking ahead, the foundation plans to expand the lab's portfolio, inviting applications from promising Rust initiatives. This could catalyze innovations in areas like embedded systems and blockchain, where Rust's efficiency shines."

Their article notes that the Rust Foundation "sees the lab as a way to accelerate innovation while mitigating the operational burdens that often hinder open-source development." [T]he Foundation aims to provide a stable, neutral environment for select Rust endeavors, complete with governance oversight, legal and administrative backing, and fiscal sponsorship... At its core, the Rust Innovation Lab addresses a growing need within the developer community for structured support amid Rust's rising adoption in sectors like systems programming and web infrastructure. By offering a "home" for projects that might otherwise struggle with sustainability, the lab ensures continuity and scalability. This comes at a time when Rust's memory safety features are drawing attention from major tech firms, including those in cloud computing and cybersecurity, as a counter to vulnerabilities plaguing languages like C++...

Industry observers note that such fiscal sponsorship could prove transformative, enabling projects to secure funding from diverse sources while maintaining independence. The Rust Foundation's involvement ensures compliance with best practices, potentially attracting more corporate backers wary of fragmented open-source efforts... By providing a neutral venue, the foundation aims to prevent the pitfalls seen in other ecosystems, such as project abandonment due to maintainer burnout or legal entanglements... For industry insiders, the Rust Innovation Lab represents a strategic evolution, potentially accelerating Rust's integration into mission-critical systems.

"I'm still teaching at Princeton," 83-year-old Brian Kernighan recently told an audience at New Jersey's InfoAge Science and History Museums.

And last month the video was uploaded to YouTube, a new article points out, "showing that his talk ended with a unique question-and-answer session that turned almost historic..." "Do you think there's any sort of merit to Rust replacing C?" one audience member asked... "Or is this just a huge hype bubble that's waiting to die down...?"

'"I have written only one Rust program, so you should take all of this with a giant grain of salt," he said. "And I found it a — pain... I just couldn't grok the mechanisms that were required to do memory safety, in a program where memory wasn't even an issue!" Speaking of Rust, Kernighan said "The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow. And the compiler was slow, the code that came out was slow..."

All in all, Kernighan had had a bad experience. "When I tried to figure out what was going on, the language had changed since the last time somebody had posted a description! And so it took days to write a program which in other languages would take maybe five minutes..." It was his one and only experience with the language, so Kernighan acknowledged that when it comes to Rust "I'm probably unduly cynical. "But I'm — I don't think it's gonna replace C right away, anyway."
Kernighan was also asked about NixOS and HolyC — but his formative experiences remain rooted in Bell Labs starts in the 1970s, where he remembers it was "great fun to hang out with these people."

And he acknowledged that the descendants of Unix now power nearly every cellphone. "I find it intriguing... And I also find it kind of irritating that underneath there is a system that I could do things with — but I can't get at it!"


Kernighan answered questions from Slashdot readers in 2009 and again in 2015...

More than 30,000 Python developers from around the world answered questions for the Python Software Foundation's annual survey — and PSF Fellow Michael Kennedy tells the Python community what they've learned in a new blog post. Some highlights: Most still use older Python versions despite benefits of newer releases... Many of us (15%) are running on the very latest released version of Python, but more likely than not, we're using a version a year old or older (83%). [Although less than 1% are using "Python 3.5 or lower".] The survey also indicates that many of us are using Docker and containers to execute our code, which makes this 83% or higher number even more surprising... You simply choose a newer runtime, and your code runs faster. CPython has been extremely good at backward compatibility. There's rarely significant effort involved in upgrading... [He calculates some cloud users are paying up to $420,000 and $5.6M more in compute costs.] If your company realizes you are burning an extra $0.4M-$5M a year because you haven't gotten around to spending the day it takes to upgrade, that'll be a tough conversation...

Rust is how we speed up Python now... The Python Language Summit of 2025 revealed that "Somewhere between one-quarter and one-third of all native code being uploaded to PyPI for new projects uses Rust", indicating that "people are choosing to start new projects using Rust". Looking into the survey results, we see that Rust usage grew from 27% to 33% for binary extensions to Python packages... [The blog post later advises Python developers to learn to read basic Rust, "not to replace Python, but to complement it," since Rust "is becoming increasingly important in the most significant portions of the Python ecosystem."]

PostgreSQL is the king of Python databases, and only it's growing, going from 43% to 49%. That's +14% year over year, which is remarkable for a 28-year-old open-source project... [E]very single database in the top six grew in usage year over year. This is likely another indicator that web development itself is growing again, as discussed above...

[N]early half of the respondents (49%) plan to try AI coding agents in the coming year. Program managers at major tech companies have stated that they almost cannot hire developers who don't embrace agentic AI. The productive delta between those using it and those who avoid it is simply too great (estimated at about 30% greater productivity with AI).
It's their eighth annual survey (conducted in collaboration with JetBrains last October and November). But even though Python is 34 years old, it's still evolving. "In just the past few months, we have seen two new high-performance typing tools released," notes the blog post. (The ty and Pyrefly typecheckers — both written in Rust.) And Python 3.14 will be the first version of Python to completely support free-threaded Python... Just last week, the steering council and core developers officially accepted this as a permanent part of the language and runtime... Developers and data scientists will have to think more carefully about threaded code with locks, race conditions, and the performance benefits that come with it. Package maintainers, especially those with native code extensions, may have to rewrite some of their code to support free-threaded Python so they themselves do not enter race conditions and deadlocks.

There is a massive upside to this as well. I'm currently writing this on the cheapest Apple Mac Mini M4. This computer comes with 10 CPU cores. That means until this change manifests in Python, the maximum performance I can get out of a single Python process is 10% of what my machine is actually capable of. Once free-threaded Python is fully part of the ecosystem, I should get much closer to maximum capacity with a standard Python program using threading and the async and await keywords.
Some other notable findings from the survey:

• Data science is now over half of all Python. This year, 51% of all surveyed Python developers are involved in data exploration and processing, with pandas and NumPy being the tools most commonly used for this.

• Exactly 50% of respondents have less than two years of professional coding experience! And 39% have less than two years of experience with Python (even in hobbyist or educational settings)...

• "The survey tells us that one-third of devs contributed to open source. This manifests primarily as code and documentation/tutorial additions."

Since 2023 the Python Software Foundation has had a Security Developer-in-Residence (sponsored by the Open Source Security Foundation's vulnerability-finding "Alpha-Omega" project). And he's just published a new 11-page white paper about open source's "phantom dependencies" problem — suggesting a way to solve it.

"Phantom" dependencies aren't tracked with packaging metadata, manifests, or lock files, which makes them "not discoverable" by tools like vulnerability scanners or compliance and policy tools. So Python security developer-in-residence Seth Larson authored a recently-accepted Python Enhancement Proposal offering an easy way for packages to provide metadata through Software Bill-of-Materials (SBOMs). From the whitepaper: Python Enhancement Proposal 770 is backwards compatible and can be enabled by default by tools, meaning most projects won't need to manually opt in to begin generating valid PEP 770 SBOM metadata. Python is not the only software package ecosystem affected by the "Phantom Dependency" problem. The approach using SBOMs for metadata can be remixed and adopted by other packaging ecosystems looking to record ecosystem-agnostic software metadata...

Within Endor Labs' [2023 dependencies] report, Python is named as one of the most affected packaging ecosystems by the "Phantom Dependency" problem. There are multiple reasons that Python is particularly affected:

- There are many methods for interfacing Python with non-Python software, such as through the C-API or FFI. Python can "wrap" and expose an easy-to-use Python API for software written in other languages like C, C++, Rust, Fortran, Web Assembly, and more.

- Python is the premier language for scientific computing and artificial intelligence, meaning many high-performance libraries written in system languages need to be accessed from Python code.

- Finally, Python packages have a distribution type called a "wheel", which is essentially a zip file that is "installed" by being unzipped into a directory, meaning there is no compilation step allowed during installation. This is great for being able to inspect a package before installation, but it means that all compiled languages need to be pre-compiled into binaries before installation...


When designing a new package metadata standard, one of the top concerns is reducing the amount of effort required from the mostly volunteer maintainers of packaging tools and the thousands of projects being published to the Python Package Index... By defining PEP 770 SBOM metadata as using a directory of files, rather than a new metadata field, we were able to side-step all the implementation pain...

We'll be working to submit issues on popular open source SBOM and vulnerability scanning tools, and gradually, Phantom Dependencies will become less of an issue for the Python package ecosystem.
The white paper "details the approach, challenges, and insights into the creation and acceptance of PEP 770 and adopting Software Bill-of-Materials (SBOMs) to improve the measurability of Python packages," explains an announcement from the Python Software Foundation. And the white paper ends with a helpful note.

"Having spoken to other open source packaging ecosystem maintainers, we have come to learn that other ecosystems have similar issues with Phantom Dependencies. We welcome other packaging ecosystems to adopt Python's approach with PEP 770 and are willing to provide guidance on the implementation."

Thursday saw the release of Rust 1.89.0 But this week the Rust Foundation also released its second comprehensive annual technology report.

A Rust Foundation announcement shares some highlights: - Trusted Publishing [GitHub Actions authentication using cryptographically signed tokens] fully launched on crates.io, enhancing supply chain security and streamlining workflows for maintainers.

- Major progress on crate signing infrastructure using The Update Framework (TUF), including three full repository implementations and stakeholder consensus.

- Integration of the Ferrocene Language Specification (FLS) into the Rust Project, marking a critical step toward a formal Rust language specification [and "laying the groundwork for broader safety certification and formal tooling."]

- 75% reduction in CI infrastructure costs while maintaining contributor workflow stability. ["All Rust repositories are now managed through Infrastructure-as-Code, improving maintainability and security."]

- Expansion of the Safety-Critical Rust Consortium, with multiple international meetings and advances on coding guidelines aligned with safety standards like MISRA. ["The consortium is developing practical coding guidelines, aligned tooling, and reference materials to support regulated industries — including automotive, aerospace, and medical devices — adopting Rust."]

- Direct engagement with ISO C++ standards bodies and collaborative Rust-C++ exploration... The Foundation finalized its strategic roadmap, participated in ISO WG21 meetings, and initiated cross-language tooling and documentation planning. These efforts aim to unlock Rust adoption across legacy C++ environments without sacrificing safety.
The Rust Foundation also acknowledges continued funding from OpenSSF's Alpha-Omega Project and "generous infrastructure donations from organizations like AWS, GitHub, and Mullvad VPN" to the Foundation's Security Initiative, which enabled advances like including GitHub Secret Scanning and automated incident response to "Trusted Publishing" and the integration of vulnerability-surfacing capabilities into crates.io.

There was another announcement this week. In November AWS and the Rust Foundation crowdsourced "an effort to verify the Rust standard library" — and it's now resulted in a new formal verification tool called "Efficient SMT-based Context-Bounded Model Checker" (or ESBMCESBMC) This winning contribution adds ESBMC — a state-of-the-art bounded model checker — to the suite of tools used to analyze and verify Rust's standard library. By integrating through Goto-Transcoder, they enabled ESBMC to operate seamlessly in the Rust verification workflow, significantly expanding the scope and flexibility of verification efforts...

This achievement builds on years of ongoing collaboration across the Rust and formal verification communities... The collaboration has since expanded. In addition to verifying the Rust standard library, the team is exploring the use of formal methods to validate automated C-to-Rust translations, with support from AWS. This direction, highlighted by AWS Senior Principal Scientist Baris Coskun and celebrated by the ESBMC team in a recent LinkedIn post, represents an exciting new frontier for Rust safety and verification tooling.

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.

This week Google's Open Source Security Team announced "a new project to strengthen trust in open source package ecosystems" — by reproducing upstream artifacts.

It includes automation to derive declarative build definitions, new "build observability and verification tools" for security teams, and even "infrastructure definitions" to help organizations rebuild, sign, and distribute provenance by running their own OSS Rebuild instances. (And as part of the initiative, the team also published SLSA Provenance attestations "for thousands of packages across our supported ecosystems.") Our aim with OSS Rebuild is to empower the security community to deeply understand and control their supply chains by making package consumption as transparent as using a source repository. Our rebuild platform unlocks this transparency by utilizing a declarative build process, build instrumentation, and network monitoring capabilities which, within the SLSA Build framework, produces fine-grained, durable, trustworthy security metadata. Building on the hosted infrastructure model that we pioneered with OSS Fuzz for memory issue detection, OSS Rebuild similarly seeks to use hosted resources to address security challenges in open source, this time aimed at securing the software supply chain... We are committed to bringing supply chain transparency and security to all open source software development. Our initial support for the PyPI (Python), npm (JS/TS), and Crates.io (Rust) package registries — providing rebuild provenance for many of their most popular packages — is just the beginning of our journey...

OSS Rebuild helps detect several classes of supply chain compromise:

- Unsubmitted Source Code: When published packages contain code not present in the public source repository, OSS Rebuild will not attest to the artifact.

- Build Environment Compromise: By creating standardized, minimal build environments with comprehensive monitoring, OSS Rebuild can detect suspicious build activity or avoid exposure to compromised components altogether.

- Stealthy Backdoors: Even sophisticated backdoors like xz often exhibit anomalous behavioral patterns during builds. OSS Rebuild's dynamic analysis capabilities can detect unusual execution paths or suspicious operations that are otherwise impractical to identify through manual review.


For enterprises and security professionals, OSS Rebuild can...

— Enhance metadata without changing registries by enriching data for upstream packages. No need to maintain custom registries or migrate to a new package ecosystem.

— Augment SBOMs by adding detailed build observability information to existing Software Bills of Materials, creating a more complete security picture...

- Accelerate vulnerability response by providing a path to vendor, patch, and re-host upstream packages using our verifiable build definitions...


The easiest (but not only!) way to access OSS Rebuild attestations is to use the provided Go-based command-line interface.
"With OSS Rebuild's existing automation for PyPI, npm, and Crates.io, most packages obtain protection effortlessly without user or maintainer intervention."

Google has announced OSS Rebuild, a new project designed to detect supply chain attacks in open source software by independently reproducing and verifying package builds across major repositories. The initiative, unveiled by the company's Open Source Security Team, targets PyPI (Python), npm (JavaScript/TypeScript), and Crates.io (Rust) packages.

The system, the company said, automatically creates standardized build environments to rebuild packages and compare them against published versions. OSS Rebuild generates SLSA Provenance attestations for thousands of packages, meeting SLSA Build Level 3 requirements without requiring publisher intervention. The project can identify three classes of compromise: unsubmitted source code not present in public repositories, build environment tampering, and sophisticated backdoors that exhibit unusual execution patterns during builds.

Google cited recent real-world attacks including solana/webjs (2024), tj-actions/changed-files (2025), and xz-utils (2024) as examples of threats the system addresses. Open source components now account for 77% of modern applications with an estimated value exceeding $12 trillion. The project builds on Google's hosted infrastructure model previously used for OSS Fuzz memory issue detection.

NVIDIA has released additional open-source header files for its Blackwell and Hopper GPU architectures, continuing its effort to support open-source drivers like Nouveau/NVK and the NOVA Rust driver. Phoronix reports: Last week NVIDIA open-sourced 12k lines of C header files for Blackwell GPUs to help in the open-source driver efforts, namely for Nouveau / NVK and the in-development NOVA Rust driver. On Friday they made public some additional header files for helping in the Blackwell and Hopper open-source driver enablement.

Following the previously-covered open-source header activity, on Friday this commit was pushed to their open-source documentation repository that provides Hopper and Blackwell DMA-copy class header files. [...] In turn the code has already been imported into Mesa Git.

Mozilla will ship WebGPU support in Firefox 141 when the browser launches July 22, bringing graphics processing capabilities that Chrome users have had since 2023. The initial release supports Windows only, with Mac, Linux, and Android planned for the coming months.

WebGPU provides web content direct access to graphics processors for high-performance computation and rendering in games and complex 3D applications. Chrome gained WebGPU support with version 113 in 2023, while Safari 26 is expected to add the feature this fall. Firefox's implementation uses the WGPU Rust crate, which translates web requests into native commands for Direct3D 12, Metal, or Vulkan.

An anonymous reader shared this report from InfoWorld: Tiobe CEO Paul Jansen says Ada, a system programming language whose initial development dates back to the late 1970s, could outlast similarly aged languages like Visual Basic, Perl, and Fortran in the language popularity race.

In comments on this month's Tiobe language popularity index, posted July 9, Jansen said the index has not seen much change among leading languages such as Python, C#, and Java over the past two years. But there is more movement among older languages such as Visual Basic, SQL, Fortran, Ada, Perl, and Delphi, said Jansen. Every time one of these languages is expected to stay in the top 10, it is replaced by another language, he said. Even more remarkably, newer languages have yet to rise above them. "Where are Rust, Kotlin, Dart, and Julia? Apparently, established languages are hot."
"Which one will win? Honestly, this is very hard to tell," Jansen writes, "but I would put my bets on Ada. With the ever-stronger demands on security, Ada is, as a system programming language in the safety-critical domain, likely the best survivor."

Perhaps proving his point, one year ago, Ada was ranked #24 — but on this month's index it ranks #9. (Whereas the eight languages above it all remain in the exact same positions they held a year ago...)

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