"Firefox is dead to me," wrote Steven J. Vaughan-Nichols last month for The Register, complaining about everything from layoffs at Mozilla to Firefox's discontinuation of Pocket and Fakespot, its small market share, and some user complaints that the browser might be becoming slower. But a new rebuttal (also published by The Register) argues instead that Mozilla just has "a management layer that doesn't appear to understand what works for its product nor which parts of it matter most to users..."

"Steven's core point is correct. Firefox is in a bit of a mess — but, seriously, not such a bad mess. You're still better off with it — or one of its forks, because this is FOSS — than pretty much any of the alternatives." Like many things, unfortunately, much of computing is run on feelings, tradition, and group loyalties, when it should use facts, evidence, and hard numbers. Don't bother saying Firefox is getting slower. It's not. It's faster than it has been in years. Phoronix, the go-to site for benchmarks on FOSS stuff, just benchmarked 21 versions, and from late 2023 to now, Firefox has steadily got faster and faster...

Ever since Firefox 1.0 in 2004, Firefox has never had to compete. It's been attached like a mosquito to an artery to the Google cash firehose... Mozilla's leadership is directionless and flailing because it's never had to do, or be, anything else. It's never needed to know how to make a profit, because it never had to make a profit. It's no wonder it has no real direction or vision or clue: it never needed them. It's role-playing being a business. Like we said, don't blame the app. You're still better off with Firefox or a fork such as Waterfox. Chrome even snoops on you when in incognito mode...

One observer has been spectating and commentating on Mozilla since before it was a foundation — one of its original co-developers, Jamie Zawinksi... Zawinski has repeatedly said: "Now hear me out, but What If...? browser development was in the hands of some kind of nonprofit organization?"

"In my humble but correct opinion, Mozilla should be doing two things and two things only:

— Building THE reference implementation web browser, and
— Being a jugular-snapping attack dog on standards committees.
— There is no 3."


Perhaps this is the only viable resolution. Mozilla, for all its many failings, has invented a lot of amazing tech, from Rust to Servo to the leading budget phone OS. It shouldn't be trying to capitalize on this stuff. Maybe encourage it to have semi-independent spinoffs, such as Thunderbird, and as KaiOS ought to be, and as Rust could have been. But Zawinski has the only clear vision and solution we've seen yet. Perhaps he's right, and Mozilla should be a nonprofit, working to fund the one independent, non-vendor-driven, standards-compliant browser engine.

An anonymous reader shared this report from the tech news site The Register: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) this week published guidance urging software developers to adopt memory-safe programming languages. "The importance of memory safety cannot be overstated," the inter-agency report says...

The CISA/NSA report revisits the rationale for greater memory safety and the government's calls to adopt memory-safe languages (MSLs) while also acknowledging the reality that not every agency can change horses mid-stream. "A balanced approach acknowledges that MSLs are not a panacea and that transitioning involves significant challenges, particularly for organizations with large existing codebases or mission-critical systems," the report says. "However, several benefits, such as increased reliability, reduced attack surface, and decreased long-term costs, make a strong case for MSL adoption."

The report cites how Google by 2024 managed to reduce memory safety vulnerabilities in Android to 24 percent of the total. It goes on to provide an overview of the various benefits of adopting MSLs and discusses adoption challenges. And it urges the tech industry to promote memory safety by, for example, advertising jobs that require MSL expertise.

It also cites various government projects to accelerate the transition to MSLs, such as the Defense Advanced Research Projects Agency (DARPA) Translating All C to Rust (TRACTOR) program, which aspires to develop an automated method to translate C code to Rust. A recent effort along these lines, dubbed Omniglot, has been proposed by researchers at Princeton, UC Berkeley, and UC San Diego. It provides a safe way for unsafe libraries to communicate with Rust code through a Foreign Function Interface....

"Memory vulnerabilities pose serious risks to national security and critical infrastructure," the report concludes. "MSLs offer the most comprehensive mitigation against this pervasive and dangerous class of vulnerability."
"Adopting memory-safe languages can accelerate modern software development and enhance security by eliminating these vulnerabilities at their root," the report concludes, calling the idea "an investment in a secure software future."

"By defining memory safety roadmaps and leading the adoption of best practices, organizations can significantly improve software resilience and help ensure a safer digital landscape."

Microsoft has released a modern, open-source version of its classic MS-DOS Editor -- built with Rust and compatible with Windows, macOS, and Linux. It's now simple called "Edit." Ars Technica reports: Aside from ease of use, Microsoft's main reason for creating the new version of Edit stems from a peculiar gap in modern Windows. "What motivated us to build Edit was the need for a default CLI text editor in 64-bit versions of Windows," writes [Christopher Nguyen, a product manager on Microsoft's Windows Terminal team] while referring to the command-line interface, or CLI. "32-bit versions of Windows ship with the MS-DOS editor, but 64-bit versions do not have a CLI editor installed inbox." [...]

Linux users can download Edit from the project's GitHub releases page or install it through an unofficial snap package. Oh, and if you're a fan of the vintage editor and crave a 16-bit text-mode for your retro machine that actually runs MS-DOS, you can download a copy on the Internet Archive. [...]

At 250KB, the new Edit maintains the lightweight philosophy of its predecessor while adding features the original couldn't dream of: Unicode support, regular expressions, and the ability to handle gigabyte-sized files. The original editor was limited to files smaller than 300KB depending on available conventional memory -- a constraint that seems quaint in an era of terabyte storage. But the web publication OMG! Ubuntu found that the modern Edit not only "works great on Ubuntu" but noted its speed when handling gigabyte-sized documents.

The developer-focused analyst firm RedMonk releases twice-a-year rankings of programming language popularity. This week they also released a handy graph showing the movement of top 20 languages since 2012. Their current rankings for programming language popularity...

1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. TypeScript
7. CSS
8. C++
9. Ruby
10. C

The chart shows that over the years the rankings really haven't changed much (other than a surge for TypeScript and Python, plus a drop for Ruby). JavaScript has consistently been #1 (except in two early rankings, where it came in behind Java). And in 2020 Java finally slipped from #2 down to #3, falling behind... Python. Python had already overtaken PHP for the #3 spot in 2017, pushing PHP to a steady #4. C# has maintained the #5 spot since 2014 (though with close competition from both C++ and CSS). And since 2021 the next four spots have been held by Ruby, C, Swift, and R.

The only change in the current top 20 since the last ranking "is Dart dropping from a tie with Rust at 19 into sole possession of 20," writes RedMonk co-founder Stephen O'Grady. "In the decade and a half that we have been ranking these languages, this is by far the least movement within the top 20 that we have seen. While this is to some degree attributable to a general stasis that has settled over the rankings in recent years, the extraordinary lack of movement is likely also in part a manifestation of Stack Overflow's decline in query volume..." The arrival of AI has had a significant and accelerating impact on Stack Overflow, which comprises one half of the data used to both plot and rank languages twice a year... Stack Overflow's value from an observational standpoint is not what it once was, and that has a tangible impact, as we'll see....

As that long time developer site sees fewer questions, it becomes less impactful in terms of driving volatility on its half of the rankings axis, and potentially less suggestive of trends moving forward... [W]e're not yet at a point where Stack Overflow's role in our rankings has been deprecated, but the conversations at least are happening behind the scenes.
"The veracity of the Stack Overflow data is increasingly questionable," writes RedMonk's research director: When we use Stack Overflow for programming language rankings we measure how many questions are asked using specific programming language tags... While other pieces, like Matt Asay's AI didn't kill Stack Overflow are right to point out that the decline existed before the advent of AI coding assistants, it is clear that the usage dramatically decreased post 2023 when ChatGPT became widely available. The number of questions asked are now about 10% what they were at Stack Overflow's peak.
"RedMonk is continuing to evaluate the quality of this analysis," the research director concludes, arguing "there is value in long-lived data, and seeing trends move over a decade is interesting and worthwhile. On the other hand, at this point half of the data feeding the programming language rankings is increasingly stale and of questionable value on a going-forward basis, and there is as of now no replacement public data set available.

"We'll continue to watch and advise you all on what we see with Stack Overflow's data."

Meta and AWS have used Rust, and Netflix uses Go,reports the programming news site InfoQ. But using another language, Apple recently "migrated its global Password Monitoring service from Java to Swift, achieving a 40% increase in throughput, and significantly reducing memory usage."

This freed up nearly 50% of their previously allocated Kubernetes capacity, according to the article, and even "improved startup time, and simplified concurrency." In a recent post, Apple engineers detailed how the rewrite helped the service scale to billions of requests per day while improving responsiveness and maintainability... "Swift allowed us to write smaller, less verbose, and more expressive codebases (close to 85% reduction in lines of code) that are highly readable while prioritizing safety and efficiency."

Apple's Password Monitoring service, part of the broader Password app's ecosystem, is responsible for securely checking whether a user's saved credentials have appeared in known data breaches, without revealing any private information to Apple. It handles billions of requests daily, performing cryptographic comparisons using privacy-preserving protocols. This workload demands high computational throughput, tight latency bounds, and elastic scaling across regions... Apple's previous Java implementation struggled to meet the service's growing performance and scalability needs. Garbage collection caused unpredictable pause times under load, degrading latency consistency. Startup overhead — from JVM initialization, class loading, and just-in-time compilation, slowed the system's ability to scale in real time. Additionally, the service's memory footprint, often reaching tens of gigabytes per instance, reduced infrastructure efficiency and raised operational costs.

Originally developed as a client-side language for Apple platforms, Swift has since expanded into server-side use cases.... Swift's deterministic memory management, based on reference counting rather than garbage collection (GC), eliminated latency spikes caused by GC pauses. This consistency proved critical for a low-latency system at scale. After tuning, Apple reported sub-millisecond 99.9th percentile latencies and a dramatic drop in memory usage: Swift instances consumed hundreds of megabytes, compared to tens of gigabytes with Java.
"While this isn't a sign that Java and similar languages are in decline," concludes InfoQ's article, "there is growing evidence that at the uppermost end of performance requirements, some are finding that general-purpose runtimes no longer suffice."

In 1989 a computer scientist argued that more functionality in software actually lowers usability and practicality — leading to the counterintuitive proposition that "worse is better". But is that still true?

Python's original creator Guido van Rossum addressed the question last month in a lightning talk at the annual Python Language Summit 2025. Guido started by recounting earlier periods of Python development from 35 years ago, where he used UNIX "almost exclusively" and thus "Python was greatly influenced by UNIX's 'worse is better' philosophy"... "The fact that [Python] wasn't perfect encouraged many people to start contributing. All of the code was straightforward, there were no thoughts of optimization... These early contributors also now had a stake in the language; [Python] was also their baby"...

Guido contrasted early development to how Python is developed now: "features that take years to produce from teams of software developers paid by big tech companies. The static type system requires an academic-level understanding of esoteric type system features." And this isn't just Python the language, "third-party projects like numpy are maintained by folks who are paid full-time to do so.... Now we have a huge community, but very few people, relatively speaking, are contributing meaningfully."

Guido asked whether the expectation for Python contributors going forward would be that "you had to write a perfect PEP or create a perfect prototype that can be turned into production-ready code?" Guido pined for the "old days" where feature development could skip performance or feature-completion to get something into the hands of the community to "start kicking the tires". "Do we have to abandon 'worse is better' as a philosophy and try to make everything as perfect as possible?" Guido thought doing so "would be a shame", but that he "wasn't sure how to change it", acknowledging that core developers wouldn't want to create features and then break users with future releases.

Guido referenced David Hewitt's PyO3 talk about Rust and Python, and that development "was using worse is better," where there is a core feature set that works, and plenty of work to be done and open questions. "That sounds a lot more fun than working on core CPython", Guido paused, "...not that I'd ever personally learn Rust. Maybe I should give it a try after," which garnered laughter from core developers.

"Maybe we should do more of that: allowing contributors in the community to have a stake and care".

unixbhaskar shares a report from Phoronix: The X86_NATIVE_CPU Kconfig build time option has been merged for the Linux 6.16 merge window as an easy means of enforcing "-march=native" compiler behavior on AMD and Intel processors to optimize your kernel build for the local CPU architecture/family of your system. For those wanting to "-march=native" your Linux kernel build on AMD/Intel x86_64 processors, the new CONFIG_X86_NATIVE_CPU option can be easily enabled for setting that compiler option on your local kernel builds.

The CONFIG_X86_NATIVE_CPU option is honored if compiling the Linux x86_64 kernel with GCC or LLVM Clang when using Clang 19 or newer due to a compiler bug with the Linux kernel on older compiler versions. In addition to setting the "-march=native" compiler option for the Linux kernel C code, enabling this new Kconfig build option also sets "-Ctarget-cpu=native" for the kernel's Rust code too. "It seems interesting though," comments unixbhaskar. "If the detailed benchmark shows some improvement with the option selected, then distros might start to adopt it for their flavor."

The Prossimo project (funded by the nonprofit Internet Security Research Group) seeks to "move the Internet's security-sensitive software infrastructure to memory safe code." Two years ago the Prossimo project made an announcement: they'd begun work on rav1d, a safer high performance AV1 decoder written in Rust, according to a new update: We partnered with Immunant to do the engineering work. By September of 2024 rav1d was basically complete and we learned a lot during the process. Today rav1d works well — it passes all the same tests as the dav1d decoder it is based on, which is written in C. It's possible to build and run Chromium with it.

There's just one problem — it's not quite as fast as the C version...

Our Rust-based rav1d decoder is currently about 5% slower than the C-based dav1d decoder (the exact amount differs a bit depending on the benchmark, input, and platform). This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us. The development team worked hard to get it to performance parity. We brought in a couple of other contractors who have experience with optimizing things like this. We wrote about the optimization work we did. However, we were still unable to get to performance parity and, to be frank again, we aren't really sure what to do next.

After racking our brains for options, we decided to offer a bounty pool of $20,000 for getting rav1d to performance parity with dav1d. Hopefully folks out there can help get rav1d performance advanced to where it needs to be, and ideally we and the Rust community will also learn something about how Rust performance stacks up against C.
This drew a snarky response from FFmpeg, the framework that powers audio and video processing for everyone from VLC to Twitch. "Rust is so good you can get paid $20k to make it as fast as C," they posted to their 68,300 followers on X.com.

Thanks to the It's FOSS blog for spotting the announcement.

Amazon's AWS Labs has created LLRT an experimental, lightweight JavaScript runtime designed to address the growing demand for fast and efficient serverless applications.

Slashdot reader BitterEpic wants to know what you think of it: Traditional JavaScript runtimes like Node.js rely on garbage collection, which can introduce unpredictable pauses and slow down performance, especially during cold starts in serverless environments like AWS Lambda. LLRT's manual memory management, courtesy of Rust, eliminates this issue, leading to smoother, more predictable performance. LLRT also has a runtime under 2MB, a huge reduction compared to the 100MB+ typically required by Node.js. This lightweight design means lower memory usage, better scalability, and reduced operational costs. Without the overhead of garbage collection, LLRT has faster cold start times and can initialize in milliseconds—perfect for latency-sensitive applications where every millisecond counts.

For JavaScript developers, LLRT offers the best of both worlds: rapid development with JavaScript's flexibility, combined with Rust's performance. This means faster, more scalable applications without the usual memory bloat and cold start issues. Still in beta, LLRT promises to be a major step forward for serverless JavaScript applications. By combining Rust's performance with JavaScript's flexibility, it opens new possibilities for building high-performance, low-latency applications. If it continues to evolve, LLRT could become a core offering in AWS Lambda, potentially changing how we approach serverless JavaScript development.

Would you consider Javascript as the core of your future workflow? Or maybe you would prefer to go lower level with quckjs?

Thursday was Rust's 10-year anniversary for its first stable release. "To say I'm surprised by its trajectory would be a vast understatement," writes Rust's original creator Graydon Hoare. "I can only thank, congratulate, and celebrate everyone involved... In my view, Rust is a story about a large community of stakeholders coming together to design, build, maintain, and expand shared technical infrastructure." It's a story with many actors:

- The population of developers the language serves who express their needs and constraints through discussion, debate, testing, and bug reports arising from their experience writing libraries and applications.

- The language designers and implementers who work to satisfy those needs and constraints while wrestling with the unexpected consequences of each decision.

- The authors, educators, speakers, translators, illustrators, and others who work to expand the set of people able to use the infrastructure and work on the infrastructure.

- The institutions investing in the project who provide the long-term funding and support necessary to sustain all this work over decades.

All these actors have a common interest in infrastructure.
Rather than just "systems programming", Hoare sees Rust as a tool for building infrastructure itself, "the robust and reliable necessities that enable us to get our work done" — a wide range that includes everything from embedded and IoT systems to multi-core systems. So the story of "Rust's initial implementation, its sustained investment, and its remarkable resonance and uptake all happened because the world needs robust and reliable infrastructure, and the infrastructure we had was not up to the task." Put simply: it failed too often, in spectacular and expensive ways. Crashes and downtime in the best cases, and security vulnerabilities in the worst. Efficient "infrastructure-building" languages existed but they were very hard to use, and nearly impossible to use safely, especially when writing concurrent code. This produced an infrastructure deficit many people felt, if not everyone could name, and it was growing worse by the year as we placed ever-greater demands on computers to work in ever more challenging environments...

We were stuck with the tools we had because building better tools like Rust was going to require an extraordinary investment of time, effort, and money. The bootstrap Rust compiler I initially wrote was just a few tens of thousands of lines of code; that was nearing the limits of what an unfunded solo hobby project can typically accomplish. Mozilla's decision to invest in Rust in 2009 immediately quadrupled the size of the team — it created a team in the first place — and then doubled it again, and again in subsequent years. Mozilla sustained this very unusual, very improbable investment in Rust from 2009-2020, as well as funding an entire browser engine written in Rust — Servo — from 2012 onwards, which served as a crucial testbed for Rust language features.
Rust and Servo had multiple contributors at Samsung, Hoare acknowledges, and Amazon, Facebook, Google, Microsoft, Huawei, and others "hired key developers and contributed hardware and management resources to its ongoing development." Rust itself "sits atop LLVM" (developed by researchers at UIUC and later funded by Apple, Qualcomm, Google, ARM, Huawei, and many other organizations), while Rust's safe memory model "derives directly from decades of research in academia, as well as academic-industrial projects like Cyclone, built by AT&T Bell Labs and Cornell."

And there were contributions from "interns, researchers, and professors at top academic research programming-language departments, including CMU, NEU, IU, MPI-SWS, and many others." JetBrains and the Rust-Analyzer OpenCollective essentially paid for two additional interactive-incremental reimplementations of the Rust frontend to provide language services to IDEs — critical tools for productive, day-to-day programming. Hundreds of companies and other institutions contributed time and money to evaluate Rust for production, write Rust programs, test them, file bugs related to them, and pay their staff to fix or improve any shortcomings they found. Last but very much not least: Rust has had thousands and thousands of volunteers donating years of their labor to the project. While it might seem tempting to think this is all "free", it's being paid for! Just less visibly than if it were part of a corporate budget.

All this investment, despite the long time horizon, paid off. We're all better for it.
He looks ahead with hope for a future with new contributors, "steady and diversified streams of support," and continued reliability and compatability (including "investment in ever-greater reliability technology, including the many emerging formal methods projects built on Rust.")

And he closes by saying Rust's "sustained, controlled, and frankly astonishing throughput of work" has "set a new standard for what good tools, good processes, and reliable infrastructure software should be like.

"Everyone involved should be proud of what they've built."

"When Rust developers think of us C++ folks, they picture a cursed bloodline," writes professional game developer Mamadou Babaei (also a *nix enthusiast who contributes to the FreeBSD Ports collection). "To them, every line of C++ we write is like playing Russian Roulette — except all six chambers are loaded with undefined behavior." But you know what? We don't need a compiler nanny. No borrow checker. No lifetimes. No ownership models. No black magic. Not even Valgrind is required. Just raw pointers, raw determination, and a bit of questionable sanity.
He's created a video on "how to hunt down memory leaks like you were born with a pointer in one hand and a debugger in the other." (It involves using a memory leak tracker — specifically, Visual Studio's _CrtDumpMemoryLeaks, which according to its documentation "dumps all the memory blocks in the debug heap when a memory leak has occurred," identifying the offending lines and pointers.)

"If that sounds unreasonably dangerous — and incredibly fun... let's dive into the deep end of the heap."

"The method is so easy, it renders Rust's memory model (lifetimes, ownership) and the borrow checker useless!" writes Slashdot reader NuLL3rr0r. Does anybody agree with him? Share your own experiences and reactions in the comments.

And how do you feel about Rust's "borrow-checking compiler nanny"?

Long-time Slashdot reader mbessey (a Mac/iOS developer) writes: As we're coming up on the 50th anniversary of the first release of UCSD Pascal, I thought it would be interesting to poke around in it a bit, and work on some tools to bring this "portable operating system" back to life on modern hardware, in a modern language (Rust).
Wikipedia describes UCSD Pascal as "a version that ran on a custom operating system that could be ported to different platforms. A key platform was the Apple II, where it saw widespread use as Apple Pascal. This led to Pascal becoming the primary high-level language used for development in the Apple Lisa, and later, the Macintosh. Parts of the original Macintosh operating system were hand-translated into Motorola 68000 assembly language from the Pascal source code."

mbessey is chronicling their new project in a series of blog posts which begins here: The p-System was not the first portable byte-code interpreter and compiler system — that idea goes very far back, at least to the origins of the Pascal language itself. But it was arguably one of the most-successful early versions of the idea and served as an inspiration for future portable software systems (including Java's bytecode, and Infocom's Z-machine).
And they've already gotten UCSD Pascal running in an emulator and built some tools (in Rust) to transfer files to disk images. Now they're working towards writing a p-machine emulator in Rust, which they can they port to "something other than the Mac. Ideally, something small â" like an Arduino or Raspberry Pi Pico."

Longtime Slashdot reader RoccamOccam shares a blog post from the Trifecta Tech Foundation, a nonprofit organization that creates secure, open source building blocks for infrastructure software. The foundation is also the developer behind Sudo-rs. From the report: Ubuntu 25.10 is set to adopt sudo-rs by default. Sudo-rs is a memory-safe reimplementation of the widely-used sudo utility, written in the Rust programming language. This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components. [...]

The decision to adopt sudo-rs is in line with Canonical's commitment to Carefully But Purposefully increase the resilience of critical system software, by adopting Rust. Rust is a programming language with strong memory safety guarantees that eliminates many of the vulnerabilities that have historically plagued traditional C-based software. Sudo-rs is part of the Trifecta Tech Foundation's Privilege Boundary initiative, which aims to handle privilege escalation with memory-safe alternatives.

Fedora has proposed a major change for its upcoming version 43 release that aims to achieve 99% package reproducibility, addressing growing concerns about supply-chain security. According to the change proposal announced March 31, Fedora has already reached 90% reproducibility through infrastructure changes including "clamping" file modification times and implementing a Rust-based "add-determinism" tool that standardizes metadata. The remaining 10% will require individual package maintainer involvement, treating reproducibility failures as bugs.

The effort will use a public instance of rebuilderd to independently verify that binary packages can be reproduced from source code. Unlike Debian's bit-by-bit reproducibility definition, Fedora allows differences in package signatures and some metadata while requiring identical payloads. The initiative follows similar efforts by Debian and openSUSE, and comes amid heightened focus on supply-chain security after the recent XZ backdoor incident.

Back in 2023 Python's infrastructure director called it "the first step in our plan to build financial support and long-term sustainability of PyPI" while giving users "one of our most requested features: organization accounts." (That is, "self-managed teams with their own exclusive branded web addresses" to make their massive Python Package Index repository "easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages.")

Nearly two years later, they've announced that they're "making progress" on its rollout... Over the last month, we have taken some more baby steps to onboard new Organizations, welcoming 61 new Community Organizations and our first 18 Company Organizations. We're still working to improve the review and approval process and hope to improve our processing speed over time. To date, we have 3,562 Community and 6,424 Company Organization requests to process in our backlog.
They've also onboarded a PyPI Support Specialist to provide "critical bandwidth to review the backlog of requests" and "free up staff engineering time to develop features to assist in that review." (And "we were finally able to finalize our Terms of Service document for PyPI," build the tooling necessary to notify users, and initiate the Terms of Service rollout. [Since launching 20 years ago PyPi's terms of service have only been updated twice.]

In other news the security developer-in-residence at the Python Software Foundation has been continuing work on a Software Bill-of-Materials (SBOM) as described in Python Enhancement Proposal #770. The feature "would designate a specific directory inside of Python package metadata (".dist-info/sboms") as a directory where build backends and other tools can store SBOM documents that describe components within the package beyond the top-level component." The goal of this project is to make bundled dependencies measurable by software analysis tools like vulnerability scanning, license compliance, and static analysis tools. Bundled dependencies are common for scientific computing and AI packages, but also generally in packages that use multiple programming languages like C, C++, Rust, and JavaScript. The PEP has been moved to Provisional Status, meaning the PEP sponsor is doing a final review before tools can begin implementing the PEP ahead of its final acceptance into changing Python packaging standards. Seth has begun implementing code that tools can use when adopting the PEP, such as a project which abstracts different Linux system package managers functionality to reverse a file path into the providing package metadata.

Security developer-in-residence Seth Larson will be speaking about this project at PyCon US 2025 in Pittsburgh, PA in a talk titled "Phantom Dependencies: is your requirements.txt haunted?"
Meanwhile InfoWorld reports that newly approved Python Enhancement Proposal 751 will also give Python a standard lock file format.

As Rust approaches its 10th anniversary, "there is an important piece of documentation missing that many other languages provide," notes the Rust Foundation.

While there's documentation and tutorials — there's no official language specification: In December 2022, an RFC was submitted to encourage the Rust Project to begin working on a specification. After much discussion, the RFC was approved in July 2023, and work began.

Initially, the Rust Project specification team (t-spec) were interested in creating the document from scratch using the Rust Reference as a guiding marker. However, the team knew there was already an external Rust specification that was being used successfully for compiler qualification purposes — the FLS.
Thank Berlin-based Ferrous Systems, a Rust-based consultancy who assembled that description "some years ago," according to a post on the Rust blog: They've since been faithfully maintaining and updating this document for new versions of Rust, and they've successfully used it to qualify toolchains based on Rust for use in safety-critical industries. [The Rust Foundation notes it part of the consultancy's "Ferrocene" Rust compiler/toolchain.] Seeing this success, others have also begun to rely on the FLS for their own qualification efforts when building with Rust.
The Rust Foundation explains: The FLS provides a structured and detailed reference for Rust's syntax, semantics, and behavior, serving as a foundation for verification, compliance, and standardization efforts. Since Rust did not have an official language specification back then, nor a plan to write one, the FLS represented a major step toward describing Rust in a way that aligns with industry requirements, particularly in high-assurance domains.
And the Rust Project is "passionate about shipping high quality tools that enable people to build reliable software at scale," adds the Rust blog. So... It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.

With this adoption, we look forward to better integrating the FLS with the processes of the Project and to providing ongoing and increased assurances to all those who use Rust in safety-critical industries and, in particular, to those who use the FLS as part of their qualification efforts.
More from the Rust Foundation: The t-spec team wanted to avoid potential confusion from having two highly visible Rust specifications in the industry and so decided it would be worthwhile to try to integrate the FLS with the Rust Reference to create the official Rust Project specification. They approached Ferrous Systems, which agreed to contribute its FLS to the Rust Project and allow the Rust Project to take over its development and management... This generous donation will provide a clearer path to delivering an official Rust specification. It will also empower the Rust Project to oversee its ongoing evolution, providing confidence to companies and individuals already relying on the FLS, and marking a major milestone for the Rust ecosystem.

"I really appreciate Ferrous taking this step to provide their specification to the Rust Project," said Joel Marcey, Director of Technology at the Rust Foundation and member of the t-spec team. "They have already done a massive amount of legwork...." This effort will provide others who require a Rust specification with an official, authoritative reference for their work with the Rust programming language... This is an exciting outcome. A heartfelt thank you to the Ferrous Systems team for their invaluable contribution!
Marcey said the move allows the team "to supercharge our progress in the delivery of an official Rust specification."

And the co-founder of Ferrous Systems, Felix Gilcher, also sounded excited. "We originally created the Ferrocene Language Specification to provide a structured and reliable description of Rust for the certification of the Ferrocene compiler. As an open source-first company, contributing the FLS to the Rust Project is a logical step toward fostering the development of a unified, community-driven specification that benefits all Rust users."

Cloud providers like the security of running things in virtual machines "at scale" — even though VMs "are not known for having fast cold starts or a small footprint..." noted Microsoft's Open Source blog last November. So Microsoft's Azure Core Upstream team built an open source Rust library called Hyperlight "to execute functions as fast as possible while isolating those functions within a VM."

But that was just the beginning... Then, we showed how to run Rust functions really, really fast, followed by using C to [securely] run Javascript. In February 2025, the Cloud Native Computing Foundation (CNCF) voted to onboard Hyperlight into their Sandbox program [for early-stage projects].

[This week] we're announcing the release of Hyperlight Wasm: a Hyperlight virtual machine "micro-guest" that can run wasm component workloads written in many programming languages...

Traditional virtual machines do a lot of work to be able to run programs. Not only do they have to load an entire operating system, they also boot up the virtual devices that the operating system depends on. Hyperlight is fast because it doesn't do that work; all it exposes to its VM guests is a linear slice of memory and a CPU. No virtual devices. No operating system. But this speed comes at the cost of compatibility. Chances are that your current production application expects a Linux operating system running on the x86-64 architecture (hardware), not a bare linear slice of memory...

[B]uilding Hyperlight with a WebAssembly runtime — wasmtime — enables any programming language to execute in a protected Hyperlight micro-VM without any prior knowledge of Hyperlight at all. As far as program authors are concerned, they're just compiling for the wasm32-wasip2 target... Executing workloads in the Hyperlight Wasm guest isn't just possible for compiled languages like C, Go, and Rust, but also for interpreted languages like Python, JavaScript, and C#. The trick here, much like with containers, is to also include a language runtime as part of the image... Programming languages, runtimes, application platforms, and cloud providers are all starting to offer rich experiences for WebAssembly out of the box. If we do things right, you will never need to think about whether your application is running inside of a Hyperlight Micro-VM in Azure. You may never know your workload is executing in a Hyperlight Micro VM. And that's a good thing.
While a traditional virtual-device-based VM takes about 125 milliseconds to load, "When the Hyperlight VMM creates a new VM, all it needs do to is create a new slice of memory and load the VM guest, which in turn loads the wasm workload. This takes about 1-2 milliseconds today, and work is happening to bring that number to be less than 1 millisecond in the future."

And there's also double security due to Wasmtime's software-defined runtime sandbox within Hyperlight's larger VM...

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: Despite the minor delay, Linux 6.14 arrives packed with cutting-edge features and improvements to power upcoming Linux distributions, such as the forthcoming Ubuntu 25.04 and Fedora 42. The big news for desktop users is the improved NTSYNC driver, especially those who like to play Windows games or run Windows programs on Linux. This driver is designed to emulate Windows NT synchronization primitives. What that feature means for you and me is that it will significantly improve the performance of Windows programs running on Wine and Steam Play. [...] Gamers always want the best possible graphics performance, so they'll also be happy to see that Linux now supports recently launched AMD RDNA 4 graphics cards. This approach includes support for the AMD Radeon RX 9070 XT and RX 9070 graphics cards. Combine this support with the recently improved open-source RADV driver and AMD gamers should see the best speed yet on their gaming rigs.

Of course, the release is not just for gamers. Linux 6.14 also includes several AMD and Intel processor enhancements. These boosts focus on power management, thermal control, and compute performance optimizations. These updates are expected to improve overall system efficiency and performance. This release also comes with the AMDXDNA driver, which provides official support for AMD's neural processing units based on the XDNA architecture. This integration enables efficient execution of AI workloads, such as convolutional neural networks and large language models, directly on supported AMD hardware. While Rust has faced some difficulties in recent months in Linux, more Rust programming language abstractions have been integrated into the kernel, laying the groundwork for future drivers written in Rust. [...] Besides drivers, Miguel Ojeda, Rust for Linux's lead developer, said recently that the introduction of the macro for smart pointers with Rust 1.84: derive(CoercePointee) is an "important milestone on the way to building a kernel that only uses stable Rust functions." This approach will also make integrating C and Rust code easier. We're getting much closer to Rust being grafted into Linux's tree.

In addition, Linux 6.14 supports Qualcomm's latest Snapdragon 8 Elite mobile processor, enhancing performance and stability for devices powered by this chipset. That support means you can expect to see much faster Android-based smartphones later this year. This release includes a patch for the so-called GhostWrite vulnerability, which can be used to root some RISC-V processors. This fix will block such attacks. Additionally, Linux 6.14 includes improvements for the copy-on-write Btrfs file system/logical volume manager. These primarily read-balancing methods offer flexibility for different RAID hardware configurations and workloads. Additionally, support for uncached buffered I/O optimizes memory usage on systems with fast storage devices. Linux 6.14 is available for download here.

"TrapC, a fork of the C language, is being developed as a potential solution for memory safety issues that have hindered the C and C++ languages," reports InfoWorld.

But also being developed is a compiler named trapc "intended to be implemented as a cybersecurity compiler for C and C++ code, said developer Robin Rowe..." Due by the end of this year, trapc will be a free, open source compiler similar to Clang... Rowe said.

TrapC has pointers that are memory-safe, addressing the memory safety issue with the two languages. With TrapC, developers write in C or C++ and compile in TrapC, for memory safety...

Rowe presented TrapC at an ISO C meeting this week. Developers can download a TrapC whitepaper and offer Rowe feedback. According to the whitepaper, TrapC's memory management is automatic and cannot leak memory. Pointers are lifetime-managed, not garbage-collected. Also, TrapC reuses a few code safety features from C++, notably member functions, constructors, destructors, and the new keyword.
"TrapC Memory Safe Pointers will not buffer overrun and will not segfault," Rowe told the ISO C Committee standards body meeting, according to the Register. "When C code is compiled using a TrapC compiler, all pointers become Memory Safe Pointers and are checked."

In short, TrapC "is a programming language forked from C, with changes to make it LangSec and Memory Safe," according to that white paper. "To accomplish that, TrapC seeks to eliminate all Undefined Behavior in the C programming language..."

"The startup TRASEC and the non-profit Fountain Abode have a TrapC compiler in development, called trapc," the whitepaper adds, and their mission is "to enable recompiling legacy C code into executables that are safe by design and secure by default, without needing much code refactoring... The TRASEC trapc cybersecurity compiler with AI code reasoning is expected to release as free open source software sometime in 2025."

In November the Register offered some background on the origins of TrapC...

Memory safety bugs are "eroding trust in technology and costing billions," argues a new post on Google's security blog — adding that "traditional approaches, like code auditing, fuzzing, and exploit mitigations — while helpful — haven't been enough to stem the tide."

So the blog post calls for a "common framework" for "defining specific, measurable criteria for achieving different levels of memory safety assurance." The hope is this gives policy makers "the technical foundation to craft effective policy initiatives and incentives promoting memory safety" leading to "a market in which vendors are incentivized to invest in memory safety." ("Customers will be empowered to recognize, demand, and reward safety.")

In January the same Google security researchers helped co-write an article noting there are now strong memory-safety "research technologies" that are sufficiently mature: memory-safe languages (including "safer language subsets like Safe Buffers for C++"), mathematically rigorous formal verification, software compartmentalization, and hardware and software protections. (With hardware protections including things like ARM's Memory Tagging Extension and the (Capability Hardware Enhanced RISC Instructions, or "CHERI", architecture.) Google's security researchers are now calling for "a blueprint for a memory-safe future" — though Importantly, the idea is "defining the desired outcomes rather than locking ourselves into specific technologies."

Their blog post this week again urges a practical/actionable framework that's commonly understood, but one that supports different approaches (and allowing tailoring to specific needs) while enabling objective assessment: At Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it. We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process... This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++.

This effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement... The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design.
The security researchers' post calls for "a collective commitment" to eliminate memory-safety bugs, "anchored on secure-by-design practices..." One of the blog post's subheadings? "Let's build a memory-safe future together."

And they're urging changes "not just for ourselves but for the generations that follow."