Phoronix's Michael Larabel writes: An interesting anecdote from this month's Linux Plumbers Conference in Tokyo is that Meta (Facebook) is using the Linux scheduler originally designed for the needs of Valve's Steam Deck... On Meta Servers. Meta has found that the scheduler can actually adapt and work very well on the hyperscaler's large servers. [...] The presentation at LPC 2025 by Meta engineers was in fact titled "How do we make a Steam Deck scheduler work on large servers." At Meta they have explored SCX_LAVD as a "default" fleet scheduler for their servers that works for a range of hardware and use-cases for where they don't need any specialized scheduler. They call this scheduler built atop sched_ext as "Meta's New Default Scheduler." LAVD they found to work well across the growing CPU and memory configurations of their servers, nice load balancing between CCX/LLC boundaries, and more. Those wishing to learn more about Meta's use and research into SCX-LAVD can find the Linux Plumbers Conference presentation embedded below along with the slide deck (PDF).

Read more of this story at Slashdot.

Microsoft has a whole team dedicated to eliminating “every line of C and C++ from Microsoft by 2030,” which includes Windows 11. While C powers the bulk of the Windows kernel and low-level components, including Windows APIs (Win32), C++ is used to build native Windows apps.

Microsoft’s love for Rust is not exactly newfound, and nobody really hates Rust for all good reasons. Rust is a programming language (not to be confused with a framework like WebView2), and it’s far more secure than C, which powers most of the native code in Windows, including its kernel.

Microsoft eventually plans to replace the core Windows components, including the kernel, with a version written in Rust using AI. As delusional as this idea might sound, one of the distinguished engineers at Microsoft is actually quite confident about the company’s plans, all thanks to “AI.”

In a job listing, Galen Hunt, who has been with Microsoft for the past three decades and is currently a Distinguished Engineer, confirmed that his team has an opening for an “IC5 Principal Software Engineer.” But it’s far from a simple job listing. Windows Latest spotted some intriguing details on Microsoft’s careers and LinkedIn post.

In one of the LinkedIn posts, the company says:

“[Our] goal is to eliminate every line of C and C++ from Microsoft by 2030. Our strategy is to combine AI *and* Algorithms to rewrite Microsoft’s largest codebases.”

All of that might sound delusional if you realize Windows is primarily written in C and C++, but Microsoft insists everything is possible when an engineer can use AI to write more than a million lines of code every month.

“1 engineer, 1 month, 1 million lines of code”.

A single engineer and one million lines of code every month, and you’ll have “C and C++” eliminated from Microsoft. Microsoft is actively hiring such developers who would join the company’s “eliminate C and C++ by 2030” plan as an IC5 Principal Software Engineer.

“Our North Star is “1 engineer, 1 month, 1 million lines of code,” Microsoft’s Galen Hunt wrote in a LinkedIn post spotted by Windows Latest.

This statement follows a similar remark by Microsoft’s Satya Nadella, who previously said that up to 30% of the company’s code was written by AI, and that this likely includes Windows as well.

Microsoft says it’ll deploy AI to “modify” C and C++ code” at a large scale and achieve the target by 2030 (hopefully)

Microsoft has built a powerful “code processing infrastructure,” which likely means the company trained its AI model on C and C++ code alongside Rust. This infrastructure uses “AI Agents to make code modifications at scale.”

Microsoft is confident that its infrastructure will enable the company to evolve and translate most of the company’s largest C and C++ systems to Rust.

“Our team is part of the Future of Scalable Software Engineering group in the EngHorizons organization in Microsoft CoreAI,” a Microsoft engineer explained.

Rust is more secure than C and C++, and likely a better choice, but can we trust AI agents to “translate” the codebase?

I love Rust, and rewriting parts of Windows in Rust is not a bad idea. Rust itself sounds like a better alternative than C and C++, largely due to proven security improvements, but our concern is with the AI-driven approach, not Rust.

AI should be able to translate the syntax, but it might fail at the intent of the code, and that likely explains why we’ve had Windows updates breaking basic features like Task Manager or even causing the BitLocker recovery screen.

Rust is part of Microsoft’s efforts to make Windows more secure, while WebView2 takes care of the frontend

Microsoft has been advocating for Rust over C and C++ for nearly six years, but at that point, we had no clue that the company actually planned to dump C and C++ as soon as possible.

“What separates Rust from C and C++ is its strong safety guarantees,” Microsoft argues in a blog post from 2019. “Unless explicitly opted-out of through usage of the “unsafe” keyword, Rust is completely memory safe.”

Microsoft recently made Windows APIs ready for Rust developers. There’s also a repo on GitHub called “windows-rs,” which is a Rust projection (bindings + glue) of the Windows API, so Rust code can call Win32, COM, and WinRT the same way C++ or C# would.

Microsoft also has a separate effort for Rust driver development (windows-drivers-rs on GitHub), which shows the company is exploring Rust beyond apps, too. And it turns out this whole “optimize for Rust” was not a one-off project or fancy “open-source” work, as the company is really serious about Rust.

So far, Microsoft’s attempt to replace native languages like C++, WinUI, XAML, etc, hasn’t gone well with consumers or even enterprises. In fact, Microsoft has contributed to the broader problem, where the most popular Windows apps are RAM-consuming monsters, such as Discord or the company’s own Teams.

Windows UI is gradually shifting to web-based components. It’s not just about apps, as we have React within the Start menu. Moreover, we’re now getting WebView2 inside the Notifications Center for the Calendar’s Agenda view. This means a new Edge/WebView2 instance is triggered when you open the Notifications Center.

Only time will tell how well these “agentic” programmers will translate C and C++ code to Rust or other languages across Windows and other Microsoft products.

 

The post Microsoft confirms “eliminate C and C++” plan, translate code to Rust using AI, as Windows 11 adopts Rust and WebView2 appeared first on Windows Latest

The open source ecosystem continues to face organized, adaptive supply chain threats that spread through compromised credentials and malicious package lifecycle scripts. The most recent example is the multi-wave Shai-Hulud campaign.

While individual incidents differ in their mechanics and speed, the pattern is consistent: Adversaries learn quickly, target maintainer workflows, and exploit trust boundaries in publication pipelines.

This post distills durable lessons and actions to help maintainers and organizations harden their systems and prepare for the next campaign, not just respond to the last one. We also share more about what’s next on the npm security roadmap over the next two quarters. 

Recent Shai-Hulud Campaigns

Shai-Hulud is a coordinated, multi-wave campaign targeting the JavaScript supply chain and evolved from opportunistic compromises to engineered, targeted attacks.

The first wave focused on abusing compromised maintainer accounts. It injected malicious post install scripts to slip malicious code into packages, exfiltrate secrets, and self-replicate, demonstrating how quickly a single foothold can ripple across dependencies. 

The second wave, referred to as Shai-Hulud 2.0, escalated the threat: Its ability to self-replicate and spread via compromised credentials was updated to enable cross-victim credential exposure. The second wave also introduced endpoint command and control via self-hosted runner registration, harvesting a wider range of secrets to fuel further propagation, and destructive functionality. This wave added a focus on CI environments, changing its behavior when it detects it is running in this context and including privilege escalation techniques targeted to certain build agents. It also used a multi-stage payload that was harder to detect than the previous wave payload. The shortened timeline between variants signals an organized adversary studying community defenses and rapidly iterating around them.

Rather than isolated breaches, the Shai-Hulud campaigns target trust boundaries in maintainer workflows and CI publication pipelines, with a focus on credential harvesting and install-time execution. The defining characteristics we see across waves include:

• Credential-adjacent compromise: Attackers gain initial footholds via compromised credentials or OAuth tokens, then pivot to collect additional secrets (npm tokens, CI tokens, cloud credentials) to expand reach. This enables reuse across organizations and future waves without a single point of failure.
• Install-time execution with obfuscation: Malicious post-install or lifecycle scripts are injected into packages (or dependency chains) and only reveal behavior at runtime. Payloads are often conditionally activated (e.g., environment checks, org scopes) and exfiltrate data using techniques tailored to the environment it is running in.
• Targeting trusted namespaces and internal package names: The campaign affected popular and trusted packages, and the worm published infected packages with existing package names. The second wave also patched the version number of the package to make the infected packages look like legitimate updates and blend in with normal maintainer activity.
• Rapid iteration and engineering around defenses: Short intervals between variants and deliberate changes to bypass previous mitigations indicate an organized campaign mindset. The goal is durable access and scalable spread, not one-off opportunism.
• Review blind spots in publication pipelines: Differences between source and published artifacts, lifecycle scripts, and build-time transformations create gaps where injected behavior can land without notice if teams lack artifact validation or staged approvals.

Recent waves in this pattern reinforce that defenders should harden publication models and credential flows proactively, rather than tailoring mitigations to any single variant.

What’s Next for npm

We’re accelerating our security roadmap to address the evolving threat landscape. Moving forward, our immediate focus is on adding support for:

• Bulk OIDC onboarding: Streamlined tooling to help organizations migrate hundreds of packages to trusted publishing at scale.
• Expanded OIDC provider support: Adding support for additional CI providers beyond GitHub Actions and GitLab.
• Staged publishing: A new publication model that gives maintainers a review period before packages go live, with MFA-verified approval from package owners. This empowers teams to catch unintended changes before they reach downstream users—a capability the community has been requesting for years.

Together, these investments give maintainers stronger, more flexible tools to secure their packages at every stage of the publication process.

Advice for GitHub and npm users and maintainers

Malware like Shai-Hulud often spreads by adding malicious code to npm packages. The malicious code is executed as part of the installation of the package so that any npm user who installs the package is compromised. The malware scavenges the local system for tokens, which it can then use to continue propagating. Since npm packages often have many dependencies, by adding malware to one package, the attacker can indirectly infect many other packages. And by hoarding some of the scavenged tokens rather than using them immediately, the attacker can launch a new campaign weeks or months after the initial compromise.

In the “References” section below, we have included links to longer articles with analysis of recent campaigns and advice on how to stay secure, so we won’t rehash all of that information here. Instead, here is a short summary of our top recommendations:

Advice for everyone

• Enable phishing-resistant MFA on all your accounts, particularly for GitHub package managers like npm, PyPI, RubyGems, or NuGet, and also any accounts that could be leveraged for account takeover or phishing, like email and social media accounts.
• Always set an expiration date on tokens to ensure that they’re rotated on a regular schedule. Organizations can enforce a maximum lifetime policy.
• Audit and revoke access for unused GitHub/OAuth apps.
• Use a sandbox, such as GitHub Codespaces or a virtual machine or container, for development work. This limits the access of any malware that you accidentally run.

Advice for maintainers

• Enable branch protection so that malicious updates cannot be pushed directly to your main branch, even if the attacker has access to a valid token.
• Use npm trusted publishing instead of tokens. Trusted publishing is also available for other package managers such as PyPI, RubyGems, and NuGet.
• Pin CI dependencies, enable code scanning, and don’t forget to resolve the code scanning alerts!
• Monitor package artifacts and validate published tarballs/bundles against source (e.g., SRI or artifact build attestations).

Note that the above advice is preventative. If you believe you are a victim of an attack and need help securing your GitHub or npm account, please contact GitHub Support.

References

• Report a malicious package in npm
• Our plan for a more secure npm supply chain
• Strengthening npm security
• View malware advisories in the Advisory Database
• Quickstart for securing your repository 
• Dependency review on GitHub
• OpenSSF best practices for npm
• Microsoft’s guidance for detecting and defending
• Recent improvements to GitHub Actions

The post Strengthening supply chain security: Preparing for the next malware campaign appeared first on The GitHub Blog.

---

Andrea Kail, Matthew Kressel, and Tom Gerencer join us to discuss the Stephen King movie adaptations The Running Man, The Long Walk, The Dead Zone, and The Mist. Time stamps: The Running Man (17:44), The Long Walk (47:14), The Dead Zone (1:10:45), The Mist (1:30:20). Ad-free episodes are available to our paid supporters over at patreon.com/geeks.

Learn more about your ad choices. Visit megaphone.fm/adchoices

Download audio: https://www.podtrac.com/pts/redirect.mp3/pdst.fm/e/mgln.ai/e/495/pscrb.fm/rss/p/tracking.swap.fm/track/bwUd3PHC9DH3VTlBXDTt/traffic.megaphone.fm/SBP6130967524.mp3?updated=1766521947

---